Secure transaction controller for value token exchange systems

ABSTRACT

Systems and methods that provide improved security and scalability in digital token exchange are disclosed. A secure transaction controller may include an exchange request module, exchange matching module, and exchange execution module to facilitate the exchange of different classes of value tokens.

CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No.16/865,812 filed on May 4, 2020, which is a continuation of U.S. patentapplication Ser. No. 15/348,952 filed Nov. 10, 2016, which is acontinuation-in-part of U.S. application Ser. No. 15/184,636 filed Jun.16, 2016, and also claims priority to U.S. Provisional Application62/321,676 filed Apr. 12, 2016. The entire disclosures of saidapplications are incorporated herein by reference thereto.

BACKGROUND

Within the area of cryptography and computer security, there has beensubstantial research on the secure creation and transfer of electronicvalue. This area of research is generally termed ‘electronic cashresearch’, although its applications in practice are much wider than thecreation and circulation of electronic forms of money, as such, becausethe techniques extend to the creation and circulation of electronicvalue of any kind.

Cryptographic electronic cash systems may be based on the circulation ofso-called digital currency. Electronic cash systems are generallyclassified as ‘on-line’ or ‘off-line’. On-line systems generally requirethe verification of digital currency at transaction time in order toprovide for a secure system. The verification procedure may preventspending illegitimate copies of a digital currency.

Electronic cash systems also include both token based and account/ledgerbased systems. In an account/ledger based system, value is representedas entries in a centralised or distributed data repository, andtransactions are ledger entries containing a ‘from’ (payer) and a ‘to’(payee) account identifier and/or other information serving as a ledgerof transactions.

In some electronic digital currency token based systems value may bestored in electronic form on user's devices, much like holding abanknote, coin, or share certificate in printed or minted form. Atransaction may include sending, normally though one or more electronictransmission channels digital currency from a payer to a payee. In someprior systems, a server may maintain a record of valid serial numbersfor digital currency tokens, and the exchange value associated withthem. When such a digital currency token is provided back to the issuerfor ‘deposit’ (also referred to as ‘redemption’), it may be marked as‘invalid’ on the server records and the exchange value provided to theuser in return. An early example of such a system was called Netcash(Medvinski 1993).

Alternatively, instead of just issuing digital currency as anidentification string (serial number), digital currency can becryptographically signed by the issuer, e.g., using a cryptographicdigital signature. This allows local verification, by any user in thesystem that this signed digital currency has indeed been issued by agiven issuer. Furthermore, the issuer can add additional conditions orinformation to such a digital currency, which can then also be locallyverified as having been added by the issuer—for example, the amount ordenomination of a digital currency, or an expiry date. It will beappreciated that, in this scenario, the contents of the digital currencyand authenticity of its issuer can be verified locally. Unless thedigital signature is compromised, the digital currency cannot bemodified by a party other than the issuer. A verification check by theissuer is now required only to prevent so-called ‘double spending’ of adigital currency, that is the improper duplication of the digitalcurrency and the attempt to spend it more than once.

A further extension of digital currency with digital signatures is theuse of the so-called “blind signature” approach. This approach allowsfor a secure system where a user, not the issuer, creates unsigned‘proto digital currency tokens’, which are then provided to the issuerto sign (in what may be termed a ‘withdrawal’ transaction). At the timesdigital currency tokens are signed by the issuer, the issuer does notsee their serial numbers, nor is the issuer able to determine them.However, the issuer can securely identify the correctness anddenomination of the requested digital currency, which the issuer canthen endorse with its digital signature. In order to prevent doublespending under this system, it may be necessary to maintain and compareto a record of ‘spent’ digital currency, rather than a record of ‘valid’digital currency. That is because the issuer only effectively sees theserial number of a digital currency token at the time it is returned for‘deposit’ (or ‘redemption’). Most notably, this approach permits a userto remain anonymous during a transaction. In order to make a validpayment, the user need not disclose his identity, nor any accountrelated to his identity, to the payee, nor to the issuer. This type ofelectronic cash system is therefore seen as more ‘cash-like’ in itsproperties, in comparison with other electronic cash systems.

Existing electronic cash systems have numerous limitations andbottlenecks. In particular, these systems are often not readilyscalable, or the system security is irrevocably impacted in case of thecompromise of the signature key.

Electronic cash systems utilising digital signatures rely for theirsecurity on the security of the signature key used to sign digitalcurrency tokens. Signature keys therefore have to be heavily protected.In practice digital signature keys are usually changed at regularintervals, in order to limit exposure to risk from potential attackers.The risk level in case of a successful attack on the signature key (orits accidental or wilful disclosure) is very high, since, theoretically,the attacker can now create seemingly valid digital currency tokens inunlimited quantities. This problem is magnified by the Internet-specificproblem, namely that these improperly obtained keys can be distributedrapidly and widely, and improperly signed tokens can be very rapidlydistributed and redeemed on a wide scale, potentially without geographiclimitations.

There may often be problems with interoperability or exchangeability ofdigital currency tokens issued by different issuers.

In existing systems, the double spending check may constitute asignificant performance bottleneck. The task of checking against thedouble spending record cannot be parallelised easily, because there is arisk of potential double spending unless an unambiguously up-to-dateversion of the double spending record is being checked against.

Certain system properties and transaction monitoring, often required forregulatory and operational reporting purposes in the operation onelectronic payment systems (such as AML-Anti Money Laundering—andsuspicious transactions reporting), are difficult to achieve inelectronic cash systems as described above, particularly when anonymoustokens are employed, due to several different limitations when comparedto account based systems.

Some example embodiments described in the present disclosure includesystems and methods for handling digital currency tokens that are moresecure and more scalable, while providing improved auditability. Furtherexample embodiments provide systems and methods that allow secure,scalable and flexible exchange of tokens of different types.

SUMMARY

One example embodiment of the present invention includes an apparatusfor cryptographically signed digital tokens representing value. Theapparatus includes a processor, a memory accessible to the processor;and a secure memory readable by the processor, and storing a privateMint key. The processor is configured to receive a request from arequester to swap a previously issued Value Token and to read from thememory the Value Token, the previously issued Value token having aclass, a digital signature, and a denomination. The processor isconfigured, responsive to the request, to validate the previously issuedValue Token(s) using the digital signature, and responsive to validatingthe token(s) and the request, to cause a newly issued Value Token(s)having the class and denomination to be signed using the private Mintkey, and to send the signed newly issued Value Token(s) to therequester. The processor is configured to sign and send new intrinsicValue Token(s) only in response to requests to swap previously issuedcoded Value token(s). Optionally, validating previously issued ValueTokens includes validating a digital signature of the one or morepreviously issued Value Tokens using a public key of the Mint thatissued the previously issued Value Tokens. The public key of the Mintthat issued the previously issued Value Token may have an associatedexpiration state, the processor may be further configured to;conditioned on the original recipient of the previously issued ValueToken being unknown and the previously issued Value Token Mint keyexpiration state being active, issuing the newly issued Value Token;conditioned on the original recipient of the previously issued ValueToken being unknown and the previously issued Value Token Mint keyexpiration state being expired, refusing the request to issueconditioned on the identity of the original recipient of the previouslyissued Value Token being known and being different than the requesterand the previously issued Value Token Mint key expiration state beingactive, issuing the newly issued Value Token; conditioned on theidentity of the original recipient of the previously issued Value Tokenbeing known and being different than the requester and the previouslyissued Value Token Mint key expiration state being expired, refusing therequest to issue the newly issued Value Token conditioned on theidentity of the original recipient of the previously issued Value Tokenbeing known and the identity of the recipient being known and being thesame as the original recipient, issuing a newly issued Value Tokenirrespective of the expiration of the Mint key, the newly issued ValueToken including information identifying the recipient.

In the above examples, the apparatus may further include a datarepository storing statuses of issued tokens, the data repository incommunication with the processor, wherein the processor is furtherconfigured to, as part of validating the previously issued Value Token,to check the data repository to confirm the status of the previouslyissued Value Tokens, and prior to signing the newly issued Value Token,to cause the data repository to be updated to indicate that thepreviously issued Value Token is no longer a valid token.

In the above examples, the processor may be further configured: toreceive and swap both previously issued Value Tokens including digitalsignatures of the original recipient and previously issued Value Tokenswithout identification of the original recipient, and to issue a newlyissued Value Token without a digital signature of the requester only inresponse to a request to swap a previously issued Value Token signed bythe original recipient of the previously issued Value Token.

In the above apparatus, the previously issued Value Token may optionallyinclude information indicating at least one redemption rule. Theapparatus may further include a redemption rule module configured todetermine the redemption rule associated with the previously issuedValue Token and to cause the processor to swap the previously issuedValue Token for the newly issued Value Token only in compliance with theredemption rule.

In the above apparatus, the processor may be configured to only issue anew intrinsic Value Token not identifying the requester when thepreviously issued Value Token is a coded Value Token where the requesteris identified either in the Value Token or in a data repositoryaccessible to the processor.

Another example embodiment of the present invention includes a method oftoken swap. The method includes receiving at a Mint from a requester,optionally via a network, one or more previously issued Value Tokens,the one or more previously issued Value Tokens each including a sharedclass and a respective digital signature and denomination; receiving atthe Mint a request from the requester to swap the one or more previouslyissued Value Tokens for newly issued Value Tokens of the same class;validating by the Mint the one or more previously issued Value Tokens;responsive to receiving the request to swap and validating the one ormore previously issued Value Tokens, signing by the Mint with a digitalsignature of the Mint one or more newly issued Value Tokens having theshared class; and sending the signed one or more newly issued ValueTokens, optionally via the network, to the requester.

In the method, the one or more newly issued Value Tokens are intrinsicValue Tokens, and the one or more newly issued Value Tokens are signedand sent conditioned on the one or more previously issued Value Tokensbeing coded Value Tokens. If the one or more previously issued ValueTokens are coded Value Tokens, the method may further include: as partof the request to swap, receiving an indication as to whether thepreviously issued Value Tokens should be swapped for coded Value Tokensor intrinsic Value Tokens; signing and sending the newly issued ValueTokens as the type of tokens indicated by the received indication,wherein sending the newly issued Value Tokens as intrinsic Value Tokensis contingent on the previously issued Value Tokens being coded ValueTokens. Conditioned on the previously issued Value Tokens beingintrinsic Value Tokens, the method may require the previously issuedValue Tokens be swapped only for coded Value Tokens.

In the above method, the Mint may include a processor; a memory incommunication with the processor and storing the one or more previouslyissued Value Tokens when they are received; and a secure memorycontaining a Mint key. In this case, the one or more newly issued ValueTokens may be signed by the processor using the Mint key.

Optionally, in the above method, total of the respective denominationsof the one or more previously issued Value Tokens is the same as thetotal of the respective denominations of the one or more newly issuedValue Tokens. Optionally, the shared class may be one of a sovereigncurrency, a security, a commodity, or another class of token. Optionallyvalidating the one or more previously issued Value Tokens may includevalidating the digital signatures of the one or more previously issuedValue Tokens. Further, validating the at least one previously issuedValue Token, may optionally include checking a data repository toconfirm the status of the one or more previously issued Value Tokens;and prior to sending the one or more newly issued Value Tokens, updatingthe data repository to indicate that the one or more previously issuedValue Tokens are no longer valid tokens. Optionally, the data repositoryincludes a double spend record, and confirming the status of the one ormore previously issued Value Tokens includes confirming that the one ormore previously issued Value Tokens have not previously been swapped.Optionally, the data repository indicates status of the one or morepreviously issued Value Tokens is tainted, and conditioned on theindication that the one or more previously issued Value Tokens istainted, the method restricts swaps for such tokens to be for codedValue Tokens. Optionally, when the one or more previously issued ValueTokens are intrinsic Value Tokens, the method may include, as part ofvalidating the one or more previously issued Value Tokens, confirmingthe identity of requester.

In the above method, optionally, the one or more previously issued ValueTokens includes a digital signature of an original recipient of the oneor more previously issued Value Tokens, and validating the one or morepreviously issued Value Tokens further includes validating the digitalsignature of the original recipient for reach of the one or morepreviously issued Value Tokens. If the one or more previously issuedValue Tokens are intrinsic Value Tokens having a respective tokensignature key expiration state; the method optionally includesconditioned on any of the respective token signature key expirationstates being expired and the requester being a party other than anoriginal requester who received the Value Token when it was issued,refusing a request to swap the one or more previously issued ValueTokens; conditioned on the token signature key expiration state beingexpired and the requester being the original requester who received theone or more previously issued Value Tokens when they were issued and theone or more tokens being validated, accepting the request to swap theone or more previously issued Value Tokens; and conditioned on therespective token signature key expiration states of the one or morepreviously issued Value Tokens all being unexpired and the one or morepreviously issued Value Tokens being validated, accepting the request toswap the one or more previously issued Value Tokens independent of theidentity of the requester.

Optionally, in the above method, the one or more newly issued ValueTokens further include a respective identifier of a redemption mint,different than the mint, where the one or more newly issued Value Tokensshould be swapped. When those tokens are received for a subsequent swapas previously issued Value Tokens, conditioned on the Mint not being theredemption mint, the request to swap the one or more previously issuedValue Tokens may be rejected.

Optionally, in the above method tokens may further include at least oneof: a geographic identifier indicating a geographic area where the ValueToken is valid; a jurisdiction identifier indicating a jurisdictionwhere the Value Token is valid; a not valid before indicator configuredto indicate a time before which the Value Token cannot be swapped; a notvalid after indicator configured to indicate a time after which theValue Token cannot be swapped or a time after which the Value Tokencannot be swapped for an intrinsic Value Token. Alternatively or inaddition, the method may include determining a risk profile of thereceived token, and conditioned on the risk profile being beyond apredetermined threshold, refusing the request to swap the Value Token.Alternatively, the method may further include conditioned on the riskprofile being beyond a predetermined threshold and the request to swapthe Value Token being from a requester other than the original tokenrecipient, refusing to the request; conditioned on the requester beingthe original token recipient, accepting the request to swap the ValueToken by a requester when the risk profile is beyond the predeterminedthreshold.

The above method may optionally further include: receiving the one ormore newly issued Value Tokens from a payee who has received the one ormore newly issued Value Tokens from the requester; receiving a requestfrom the payee to swap the one or more newly issued Value Tokens;responsive to the request from the payee, validating the one or morenewly issued Value Tokens; responsive to validating the one or morenewly issued Value Tokens, signing by the Mint with a digital signatureof the Mint one or more newly issued Value Tokens having the sharedclass; and sending the signed one or more second newly issued ValueTokens to the payee.

In the above method, optionally, where the one or more newly issuedValue Tokens do not identify their original recipient, the method mayinclude in the second newly issued Value Tokens information identifyingthe payee, preferably a digital signature of the payee.

In the above method, optionally, the request may include the newlyissued Value Tokens as part of the request message. These newly issuedValue Tokens may include a blind signature of the requester whenreceived by the mint.

Another example embodiment of the present invention may include a methodof receiving a payment. The method includes: receiving by the payee anintrinsic Value Token from the payer, the intrinsic Value Tokenincluding a class, a denomination, and a Mint digital signature; sendingfrom the payee the intrinsic Value Token and a request to swap theintrinsic Value Token to a Mint associated with the intrinsic ValueToken; and receiving by the payee, in response to the request, a newcoded Value Token, the new coded Value Token having the same class anddenomination as the intrinsic Value Token and being signed by the Mintassociated with the intrinsic Value Token, the new coded Value Tokenincluding information identifying the payee. Optionally, the payer maybe a device or a software agent. The payee may also, optionally be adevice or a software agent. Optionally, the Mint associated with theintrinsic Value Token is the Mint that issued the intrinsic Value Tokenwith the mint's digital signature. Optionally, the Mint associated withthe Value Token is a Mint other than the Mint that issued the intrinsicValue Token, where the Mint is associated with the Value Token by beingidentified in redemption information associated with the intrinsic ValueToken.

Optionally, the above method may further include, prior to the sending,storing the intrinsic Value Token in a digital wallet of the payee. Themethod may also include after the receiving, storing the coded ValueToken in a digital wallet of the payer. Optionally, after the receivingthe new coded Value Token may be signed with a digital signature of thepayee, after receiving.

In one alternative, the payee may receive in response to the request anindication that the intrinsic Value Token cannot be swapped. Theindication may further indicate the Value Token cannot swapped because aredemption rule indicated by information in the Value Token has not beensatisfied. The method may further include resubmitting the Value Tokenfor redemption after the condition has been satisfied, and receiving thenew coded Value Token in response.

In the above method, optionally the intrinsic Value Token may bereceived from the digital wallet of a payer via a network.

In the above method, optionally, if the payee receives a coded ValueToken, the method may further include sending by the payee the new codedValue Token to a Mint with a request to swap the new coded Value Token;receiving in response to the request to swap the new coded Value Token anew intrinsic Value Token.

Another example embodiment of the present invention is a method forexchanging tokens of two different classes. The method may includereceiving a request from a first user to exchange first tokens in afirst class for tokens in a second class; receiving the first tokensfrom the first user; receiving a request from a second user to exchangesecond tokens in the second class for tokens in the first class;receiving the second tokens from the second user; making an escrowrequest for the first tokens to a first Mint designated for swapping ofthe first tokens; making an escrow request for the second tokens to asecond Mint designated for swapping of the second tokens; receiving aconfirmation of escrow for the first tokens; receiving a confirmation ofescrow for the second tokens; sending the first tokens to the first Mintand receiving third tokens having the same class and total value inexchange; sending the second tokens to the second Mint receiving fourthtokens having the same class and total value in exchange; sending thethird tokens to the second user; and sending the fourth tokens to thefirst user.

Optionally, the method of exchange may further include marking thestatus of the first tokens as escrowed in a token validity repositoryreadable by the first Mint in response to the escrow request for thefirst tokens; and marking the status of the second tokens as escrowed ina token validity repository readable by the second Mint in response tothe escrow request for the second tokens. Optionally, the method mayalso include receiving, responsive to the escrow request for the secondValue Tokens, a failure message, indicating the Value Tokens have notbeen escrowed and/or are not available for exchange; and responsive toreceiving the failure message, requesting a release of the escrow forthe first tokens. The method may further include sending a message tothe first user indicating that the Exchange request has not beenfulfilled.

In another example embodiment, for any of the above-described examplemethods, an article of manufacture may provided. The article may includea computer readable device have recorded there on instructions which areconfigured to, when executed by a processor, to cause the execution ofthe respective method. Another example embodiment of the presentinvention may include a system for managing the issuance of tokens. Thesystem may include at least one processor; at least one memory incommunication with the processor; a token verification module stored inthe memory configured to be executed by the processor, the Value Tokenverification module configured to verify that tokens presented for swapshould be redeemed for newly issued Value Tokens; a token certificationmodule stored in the memory and configured to certify newly issuedtokens; a token issue module configured to issue newly issued ValueTokens in response to a swap request, the token issue module configuredto issue intrinsic Value Tokens only in response to request to swapcoded Value Tokens. Optionally, the token verification module mayinclude an intrinsic Value Token verification module configured toconfirm the Value Token has not been previously exchanged by accessing adouble spend repository. Optionally, the token verification module mayinclude a coded Value Token verification module configured to validate atoken by checking a repository of information on valid tokens.Optionally, token certification module may include an intrinsic ValueToken certification module configured to receive a blinded token and tosign the blinded token with a private token signature key of the mint.Optionally, the token certification module may further include a codedValue Token certification module configured to record information in adata repository indicating the newly issued token is a valid token.

The above system may also optionally include an escrow module configuredto receive a request to escrow a token; send a response indicating theValue Token is in escrow; store an indication in a data repository thatthe Value Token is in escrow; terminate the escrow when a request toswap the Value Token is received from the escrow requester; whereinwhile the Value Token is in escrow, the token verification module isconfigured to reject requests to swap the Value Token for a newly issuedValue Token from a source other than the escrow requester.

Optionally the system may also further include a double spendingrepository stored in the memory and containing information indicatingtokens for which the Mint has issued a newly issued Value Token inexchange. The system may also further include a safe mode module,configured to, upon receipt of a safe mode instruction from a Mintoperator, to cause the token verification module to prevent anyanonymous token exchanges.[One further example embodiment of the presentinvention includes a secure transaction controller which includes aprocessor, a memory in communication with the processor, an exchangerequest module, an exchange matching module, and an exchange executionmodule. The exchange request module is stored in the memory and executedby the processor to receive a first request from a first client toexchange a first set of Value Tokens of a first respective classredeemable by a first Mint for Value tokens of a second respective classredeemable by a second Mint. Responsive to the first request, theexchange request module provides an indication to an escrow controllerin communication with the first Mint that the first set of Value Tokensshould be placed in escrow. Responsive to providing the indication, theexchange request module receives an acknowledgement confirming that thefirst set of Value Tokens is valid and has been placed in escrow.Additionally, the exchange request module receives a second request froma second client to exchange a second set of Value Tokens of the secondrespective class for Value Tokens of the first respective class.Responsive to the second request, the exchange request module provides asecond indication to an escrow controller in communication with thesecond Mint that the second set of Value Tokens should be placed inescrow. The exchange request module also receives, responsive toproviding the second indication, an acknowledgement confirming that thesecond set of Value Tokens is valid and has been placed in escrow. Theexchange matching module is stored in the memory and executed by theprocessor to determine there is a match between the first request andthe second request. The exchange execution module is stored in thememory. Additionally, the exchange execution module is executed by theprocessor to, responsive to the exchange matching module determiningthere is a match between the first request and the second request, andconditioned on the acknowledgements from the first and second Mintshaving been received, send an instruction to the first Mint to swap thefirst set of tokens for a first set of new coded Value Tokens and asecond instruction to the second Mint to swap the second set of Valuetokens for a second set of new coded Value Tokens.

In the above secure transaction controller example, the exchangeexecution module may be further executed by the processor to receive thefirst set of new coded Value Tokens from the first Mint encoded toindicate the identity of the second client as recipient and deliver thefirst set of new coded Value Tokens to the second client, and receivethe second set of new coded tokens from the second Mint encoded toconfirm the identity of the first client as recipient and deliver thesecond set of new coded Value Tokens to the first client.

Optionally, in the above secure transaction controller examples, theexchange execution module is further executed by the processor to send afirst escrow finalization message to the first client, the escrowfinalization message allowing the first client to retrieve the secondset of new coded Value Tokens from the second Mint.

In the above secure transaction controller examples, the first requestmay include an express enumerated value in the second class, and theprocessor executing the exchange matching module may match the first andsecond requests conditioned on a total express enumerated value of thesecond set of Value Tokens meeting or exceeding the express enumeratedvalue included in the first request. Additionally, the first request mayindicate a market order, and the processor executing the exchangematching module may match the first request with the a second requestchosen from a set of requests to exchange Value Tokens of the secondclass for Value Tokens of the first class. The second request may havethe highest total express enumerated value of the set of requests.

Optionally, in the above secure transaction controller examples, thesystem further includes a ruleset stored in the memory. The processorexecuting the exchange matching module may use the ruleset to match thefirst set and the second set of Value Tokens.

In the above secure transaction controller examples, the first set oftokens may further include a token of a third class that is differentthan the first class. Additionally, the second set of tokens may furtherinclude a token of a third class that is different than the secondclass.

In the above secure transaction controller examples, the indication mayfurther include a complex exchange transaction id. Additionally, theinstruction to the first Mint and the instruction to the second Mint mayinclude the complex exchange transaction id.

In the above secure transaction controller examples, the indication mayfurther include an expiry time. Optionally, the processor executing theexchange matching module may determine the matching based, at least inpart, on information sets associated with the tokens but not included insuch requests.

Another example embodiment of the present invention may include a methodof providing a secure token exchange transaction. The method includesreceiving a first request from a first client to exchange a first set ofValue Tokens of a first respective class redeemable by a first Mint forValue tokens of a second respective class redeemable by a second Mint.Responsive to receiving the first request, the method provides anindication to the first Mint that the first set of Value Tokens shouldbe placed in escrow. Responsive to providing the indication, the methodreceives an acknowledgement confirming that the first set of ValueTokens is valid and has been placed in escrow. Additionally, the methodreceives a second request from a second client to exchange a second setof Value Tokens of the second respective class for Value Tokens of thefirst respective class. Responsive to receiving the second request, themethod provides a second indication to the second Mint that the secondset of Value Tokens should be placed in escrow. Responsive to providingthe second indication, the method receives, an acknowledgementconfirming that the second set of Value Tokens is valid and has beenplaced in escrow. Additionally, the method determines there is a matchbetween the first request and the second request. Responsive todetermining there is a match between the first request and the secondrequest, and conditioned on the acknowledgements from the first andsecond Mints having been received, the method sends an instruction tothe first Mint to swap the first set of tokens for a first set of newcoded Value Tokens and a second instruction to the second Mint to swapthe second set of Value tokens for a second set of new coded ValueTokens.

Optionally, the method may further include receiving the first set ofnew coded Value Tokens from the first Mint encoded to indicate theidentity of the second client as recipient and deliver the first set ofnew coded Value Tokens to the second client, and receiving the secondset of new coded tokens from the second Mint encoded to confirm theidentity of the first client as recipient and deliver the second set ofnew coded Value Tokens to the first client.

The above method may further include sending a first escrow finalizationmessage to the first client, the escrow finalization message allowingthe first client to retrieve the second set of new coded Value Tokensfrom the second Mint.

In the above method, optionally, the first request may include a valuein the second class, the matching of the first and second requests isconditioned on a value of the second set of Value Tokens meeting orexceeding the value included in the first request.

Optionally, in the above method, the first request may indicate a marketorder. Additionally, the first request may be matched with the a secondrequest chosen from a set of requests to exchange Value Tokens of thesecond class for Value Tokens of the first class, the second requesthaving the highest total value of the set of requests.

The above method may optionally further include matching the first setand the second set of Value Tokens using a predetermined ruleset.

In the above method, the first set of tokens may further include a tokenof a third class that is different than the first class. Additionally,the second set of tokens may further include a token of a third classthat is different than the second class.

In the above method, the indication may further include a complexexchange transaction id. Additionally, the instruction to the first Mintand the instruction to the second Mint may include the complex exchangetransaction id.

In the above method, the indication may further include an expiry time.Optionally, determining there is a match may be based, at lest in part,on information sets associated with the tokens, where the informationsets are not included in such requests.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example payment ecosystem, according to an exampleembodiment of the present invention.

FIG. 2 , illustrates a Value Token swap, according to an exampleembodiment of the present invention

FIG. 3 illustrates an example payment, according to an exampleembodiment of the present invention.

FIG. 4 illustrates timelines for the various actors in the examplepayment of FIG. 4 .

FIG. 5 illustrates an example Value Token swap process, according to anexample embodiment of the present invention.

FIG. 6 illustrates an example coded Value Token issue sub-process,according to an example embodiment of the present invention.

FIG. 7 illustrates an example intrinsic Value Token issue sub-process,according to an example embodiment of the present invention.

FIG. 8 illustrates an example Mint architecture, according to an exampleembodiment of the present invention.

FIG. 9 illustrates an example token data repository, according to anexample embodiment of the present invention.

FIG. 10 illustrates an example coded Value Token data structure,according to an example embodiment of the present invention.

FIG. 11 illustrates an example Mint initialization, according to anexample embodiment of the present invention.

FIG. 12 illustrates the exchange process for exchange of tokens ofdifferent currencies, according to an example embodiment of the presentinvention.

FIG. 13 illustrates the same exchange process showing the actions ofeach participant in a separate flow.

FIG. 14 illustrates an example method for verifying a set of Coded ValueTokens by a Mint, according to an example embodiment of the presentinvention.

FIG. 15 illustrates an example complex transaction using a complextransaction id and multiple Mints, according to an example embodiment ofthe present invention.

FIG. 16 illustrates an example secure transaction controllerarchitecture, according to an example embodiment of the presentinvention.

FIG. 17 illustrates an example process flow for a Value Token exchange,using a secure transaction controller, according to an exampleembodiment of the present invention.

FIG. 18 illustrates an alternative example process flow for a ValueToken exchange, using a secure transaction controller, that includes acomplex swap transaction key according to an example embodiment of thepresent invention.

FIG. 19 illustrates an example procedure for deriving the public key,according to an example embodiment of the present invention.

FIG. 20 illustrates an example procedure for verifying an executemessage, according to an example embodiment of the present invention.

FIG. 21 illustrates an example procedure for verifying a cancel message,according to an example embodiment of the present invention.

FIG. 22 illustrates a flowchart of an example process for an exchange ofIntrinsic Value Token for a Coded Value Token.

FIG. 23 illustrates a flowchart for an example process for an exchangeof a Coded Value Token (or an escrow token) for freshly signed IntrinsicValue Token.

FIG. 24 illustrates a normal exchange in an example exchange processused for payments, according to an example embodiment of the presentinvention.

FIG. 25 illustrates a retry exchange in an example exchange process usedfor payments, according to an example embodiment of the presentinvention.

FIG. 26 illustrates resending in an example exchange process used forpayments, according to an example embodiment of the present invention.

FIG. 27 illustrates cancellation of a payment, in an example exchangeprocess used for payments, according to an example embodiment of thepresent invention.

FIG. 28 illustrates an example retry exchange of coded value tokens forintrinsic tokens, as part of a payment process, according to an exampleembodiment of the present invention.

FIG. 29 illustrates an example attempt to exchange a set of tokens whichare partially spend, according to an example embodiment of the presentinvention.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

This disclosure describes several example embodiments of apparatus andmethods that may be used to provide a payment and exchangeinfrastructure in open networks, based on the concept of Value Tokens.Value Tokens are cryptographically signed messages, representingunderlying value. Value Tokens may be created and circulated, purely indigital form. Value Tokens may include a limited set of data (or acomputer file), representing the underlying value.

The “Issuer” is the party (which could be a computer system, process,intelligent agent, or the like, in turn representing an organization orperson) that authorized the issue of the Value Token. The representedvalue of a Value Token may be in a sovereign currency. The Value Tokencould also represent other things of value, such as financialsecurities, commodities, promotional points, and/or the like, othertypes of bearer instruments, or even other Value Tokens. In some cases,the Issuer may have an obligation to accept the Value Token in exchangefor the specified represented value. Significant operational advantagesmay be obtained from using the example embodiments described herein overexisting payment infrastructure approaches (which are largely based onledgers/accounts), including improved interoperability, reduced cost,better scalability, and improved security. For convenience these may bereferred to as electronic value transfer, e.g. cash transfer, payments,etc., but the systems and methods to control their issuing andcirculation may be independent of exactly what the Value Tokensrepresent.

Using digital communications for an electronic value transfer using aValue Token, need not, at the time of transmission, correspond to anyaction on an account (or other ledger based system). Instead, ValueTokens themselves may provide support for those interactions that arefamiliar to a user previously undertaken with physical cash or sharecertificates in share trading, without the physical limitations. Forexample, at some point there may be a ‘withdrawal’ where Value Tokensare obtained in return for an account transaction, and at a subsequenttime there may be one or more transactions where some or all of suchValue Tokens are sent from one user (payer) to another (payee), and atsome further point there may be a ‘deposit’/redemption where the payeemay provide Value Tokens in return for an account entry.

A Value Token may include information associated with the valuespecified by the issuer for the Value Token, such as a unique identifiere.g., a string or serial number.

Alternatively, instead of just issuing a Value Token as anidentification string (serial number), the Value Token can becryptographically signed by the Issuer. This allows local verification,by any user in the system. Such local verification confirms that theverified Value Token has indeed been issued by a given Issuer.Furthermore, the Issuer can add additional conditions or information tosuch a Value Token. These additional conditions or information can thenalso be locally verified as having been added by the Issuer. Suchadditional information may include, for example, the amount ordenomination of a Value Token, or an expiry date. It will beappreciated, that in this scenario, the contents of the Value Token, andauthenticity of its Issuer, can be verified locally contingent onappropriate information sets for such authentication being available.Unless the digital signature is compromised, signed information cannotbe modified by a party other than the Issuer. A verification check bythe Issuer is now needed only to prevent so called ‘double spending’ ofa Value Token, that is the copying of the Value Token in an attempt tospend it more than once.

In some examples described in the present disclosure, Value Tokens andthe systems and procedures configured to handle them may also haveseveral further features that facilitate the provision of capabilitiesthat meet the demands of users, the capabilities of their devices andthe obligations of the regulating authorities (including Anti MoneyLaundering-AML). These features may include:

-   -   Provision to an end user a level of privacy and/or anonymity        available in Blind Signature based electronic cash systems while        at the same time, at a system level:        -   Resolve the scalability bottleneck of parallelizing the            double spending check, operationally, and provide the            ability to scale linearly with no upper limitation;        -   Provide capabilities for system monitoring and controls            required for operational and regulatory monitoring and            reporting.    -   Provide a capability to change Issuer signature keys, at any        time, with little or no impact on an end user.    -   Reduce the risk of loss in the event of an accidental or        malicious Issuer key disclosure, possibly to the point of being        practically zero.    -   Resolve key issues in interoperability of Value Tokens issued by        different Issuers.    -   Improve system security against attacks by ‘insiders’ as well as        ‘outsiders’.    -   Provide for a Value Token trading facility with greatly reduced        systemic exchange risk.

In some of the examples described in the present disclosure, systems andmethods are provided that employ a messaging protocol with different,alternating properties in the Value Token creation, swap, and exchangecomponents of transactions between users and between users and Issuers.This alternating property messaging protocol is structured, in part, tohelp solve the problems of rapid key dissemination and distributedattack that is specifically present when digital Value Tokens areemployed on the Internet on a large scale, as well as solving thetechnical problem of providing greatly improved scalability in digitalValue Token redemption.

For example, in the example systems and methods described herein, onlyevery other circulation of a Value Token is permitted to be anonymous(blinded). That is, an anonymous Value Token is never swapped to theIssuer for another anonymous Value Token, but instead only for a ValueToken that is traceable and that may contain one or more sets ofredemption conditions.

Because a user may swap their Value Tokens with the Issuer at any time,material impact on users is effectively avoided, by making the swap ofthe ‘non-anonymous Value Tokens’ for ‘new, anonymous Value Tokens’, atransparent or automated procedure. Despite the automation of thisprocedure, its usage may allow achievement of the technical systemproperties above, such as auditability and scalability, which havepreviously been either much more difficult, or not possible to achieve,in electronic cash system implementations.

Example System Overview

In the present disclosure, a system component that issues Value Tokensas electronically signed message is referred to as a Mint. In theexample embodiments described in the present disclosure, these ValueTokens may be created in at least two types: an Intrinsic value tokenmeans that the denomination (and, optionally other parameters) of theValue Token is fixed by the specific digital signature key used for thisspecific denomination. Optionally other parameters of such Value Tokencould also be associated with the digital signature key in the intrinsicValue Token. A Coded Value Token is a Value Token where the denominationis associated with the Value Token itself, rather than the digitalsignature, either as part of the Value Token payload or bound to theValue Token and stored elsewhere.

Value Tokens of a particular “class” all represent the same type ofvalue, e.g., the same sovereign currency, financial instrument,commodity, goods and/or service and/or the like. Optionally, class mayalso be restricted to include the Mint that issued the Value Tokens, sothat only tokens issued by the same Mint are considered to be the sameclass. This disclosure reserves the term “sovereign currency” to referto currencies issued by sovereign nations that are commonly used aslegal tender. Value Tokens representing a particular sovereign currencywould be of a different class than Value Tokens representing a differentsovereign currency.

In some example embodiments described in the present disclosure,Intrinsic Value Tokens may be used to implement Value Token transferswith optional anonymity, for example, by using Chaum blind signatureprotocols.

In some example embodiments described in the present disclosure, CodedValue Tokens may be used to implement value token transfers where theMint maintains a full audit trail of payer and payee for thetransaction. Such an audit trail may be cryptographically protected,e.g., so that only the Mint that created the audit trail has certainaccess rights to the audit trail. For example, once written, each audittrail entry might only be read by a Mint that created such a record.Coded Value Tokens can optionally have other additional propertiesencoded, for example validity timestamps, payer and/or payee details,information sets, transaction references and/or information sets (forexample invoice details), geographic information sets (such as forexample location information), device information sets (for examplesmartphone ID sets, computing device IP and/or MAC addresses) and thelike.

In some example embodiments described in the present disclosure, paymentmessages may include a message containing one or more Value Tokens.Optionally, the payment message may be encoded to a particular Payee;only the payee may present such an encoded message to the relevant Mintto redeem or swap the Value Token. Tokens may be enclosed in or with thePayment Message. Optionally, the Value Tokens themselves may includeinformation preventing them from being redeemed or swapped by someoneother than the designated Payee. We use the term “swap” to refer topresenting a Value Token, e.g., to a Mint, and receiving a Value Token,e.g., a newly issued Value Token that is issued in response to therequest to swap, in response to the request. In a swap the previouslyissued or “old” Value Token may be rendered “used” or invalid, and thenew Value Token may preferably be of the same class and denomination asthe originally presented Value Tokens. It will be appreciated that,because the Value Token is simply information, merely providing theValue Token in the swap does not prevent the party presenting the ValueToken from maintaining possession of a copy, accordingly, the swaprelies on the Mint causing the previously issued Value Token to beconsidered invalid, e.g., by updating records in a way that others candetermine that the Value Token has already been redeemed.

For the purpose of clarity in this disclosure we reserve the word“exchange” in reference to the process of Value Tokens issued by oneMint, being exchanged for Value Tokens issued by a different Mint (thatis, the exchange of Value Tokens of different classes, for example anexchange of Value Tokens representing particular shares, for ValueTokens representing a sovereign currency). We use the term “swap”, whenValue Tokens of the same Class and total denomination are swapped by asingle Mint. In some embodiments there may be, for example, appliancesor other devices that incorporate multiple Mint instances each of whichissues its own particular respective class of Value Tokens.

In some example embodiments described in the present disclosure, a Mintmay be configured to issue Value Tokens that are representative of anobligation of a single Issuer to accept these Value Tokens in exchangefor something else, e.g., goods, commodities, sovereign currency,financial assets of some kind, or other value representations. The totalamount of the value which is represented by a particular Value Token isspecified by the denomination of the Value Token.

In some example embodiments described in the present disclosure, theremay be multiple types of Mints, each with a pre-determined set offunctionalities that determine, in whole or in part, the operations ofthe Mint in respect to the Value Tokens that such Mint is responsiblefor. Mints that create Value Tokens may be persistently associated withthose Value Tokens, such that only such an issuing Mint is capable oftransacting, in line with the Mint pre-determined functionalities, thoseValue Tokens.

The Mint, and entities communicating to the mint, may use multiplelayers of encryption in the circulation, swapping, and exchange of ValueTokens. Beyond the encryption described elsewhere herein facilitatingdigital signatures by the Mint, and facilitating the basic Value Tokencreation, swapping, and exchange protocols, some additional encryptionlayers, described below, may be employed for Value Token transfermessages which are encrypted to a particular recipient (PaymentMessages).

In some example embodiments, when Value Tokens are sent from one partyto another, those Value Tokens may be encrypted together with (or haveincluded in the Value Token) a unique identifier of the recipient, torepresent that such Value Tokens are intended for the specifiedrecipient only. In this case, the Mint will only accept these ValueTokens from the specified recipient, and no other party. Thiseffectively protects the transfer of Value Tokens against eavesdropperswho may be able to intercept a Value Token transfer message on aninsecure communications channel. It is noted that one of the partiesreferred to above, may be the Mint, e.g., a party requesting a swap oftokens from a Mint may encrypt the swap message in a manner tying themessage only to the Mint, as the intended recipient, and the Mint maysimilarly issue tokens to be tied to the particular swap recipient.

A Payment Message may contain one or more Value Tokens (intrinsic orcoded), as well as optional additional information, and may be encryptedinto a single message for transfer between participants. In some exampleembodiments, further message encryption may, be used on one or moremessages between parties in the system, which may be protected usinganother layer of encryption. Entire messages may be encrypted fortransit, and cryptographic certificates may be used to unambiguouslyidentify individual participants.

In some example embodiments a registration service may operate thatauthorizes each Mint instance. The authorization may be accomplishedthrough the issuance and binding of one or more cryptographiccertificate sets. For example, such a registration service, which may insome example embodiments be distributed and/or replicated, may use PKIfor such certificate sets. Certificate issuance may be on a time limitedbasis, such that each Mint instance is only certified for one or morespecific time periods, for example 1 hour/day/week/month and/or for aspecific period, such as Monday through Friday, or 9 am to 5 pm (orother convenient business hours), such that Mint operations involvingValue Tokens may only be undertaken in these periods. For example, insome example embodiments, time limitations may be implemented usingcoded value tokens. Further limitations may be implemented by specificcurrencies, which may have for example age, time or use limitations. Forexample, a user may have to their age validated.

In some example embodiments several types of Mints may be instantiatedas system elements.

In some example embodiments, a Mint may be a separate device (includingfor example a combination of software, firmware and hardware) and thatcreates, issues and manages (including receiving and issuing) one ormore sets of Value Tokens, according to a predetermined set offunctionalities. A Mint issues such created Value Tokens as specificelectronic messages, signed with a digital signature based on a secretcryptographic key, such as those of a public key based digital signaturesystem.

In some example embodiments, a Mint device may be configured to swap aset of Value Tokens that is received by the Mint in a single atomictransaction. For example, when a set of Value Tokens is received by aMint, the Mint can, verify the validity of all the Value Tokens, in thisprocess invalidating such received Value Tokens and consequently issue anew set of Value Tokens, having the same total denominations of the sameclass as those received.

Such an approach creates an example embodiment of the system thatfacilitates the issuing of electronic value, and its transfer, both in asemi-anonymous (for example Chaum level anonymity), and in atraceable/auditable manner. This capability for a Mint to issue ValueTokens of different characteristics supports both anonymized andtraceable transactions with differing associated rule sets applied to aset of Value Tokens at the time of issuance (for example a unique securesecret between Mint and Value Token recipient) and/or at the time ofswap or exchange.

In some example embodiments a Mint will at different times, usedifferent secret keys to sign Value Tokens issued by that Mint. Thesekeys that a Mint may evaluate, may include two types of keys, ‘activekeys’ and ‘expired keys’. Active keys are those keys that are used by aMint to create new Value Tokens. An expired key is one that waspreviously an Active key but that is now no longer used to issue ValueTokens.

In some example embodiments, conditions associated with such expiredkeys, e.g. time periods, risk levels, etc., are consistent with one ormore rule sets that the Mint holds or may access for such keys. The rulesets may be time based, for example where the Mint is embodied as ahardware component in a device having access to and/or control of asecure clock and such rules distinguishing between active (where thetime periods are in compliance with the rules or expired, where the timeperiods are not in compliance). Alternatively, Mints may be based in oneor more secure cloud services. Mints may have further rules, for examplethose associated with an Issuer, such as a Financial Institution,certificate authority, share issuer, bank, public or private company,venture capital provider, credit provider (including credit card companyand/or card issuer), issuer of loyalty points, store or merchant and/orany other provider of value individual, group or any other entity and/orother system element associated with them.

When Value Tokens are presented to a Mint for swap and/or exchange, theMint may evaluate the keys of such Value Tokens. Depending on the ValueTokens' signature key state, which might include active or expired, andcomparison with one or more rule sets held by the Mint, the followingoperations might be undertaken by the Mint:

-   -   In the receipt of Value Tokens signed with active keys, the Mint        will invalidate such tokens and issue new Value Tokens (of the        same total denomination and class), signed with an active key    -   In the receipt of Value Tokens signed with expired keys, the        Mint may, as part of the evaluation and validation process,        require the sender to provide cryptographic proof of having        themselves been the prior direct recipient of such Value Tokens        from the Mint. As disclosed herein this may include payment        message encryption and the like. Only if this proof is provided,        will the Mint invalidate the Value Tokens and issue a new set of        Value Tokens, of the same class and total denominations, signed        with an active key

This approach supports a system where keys may be dynamicallyinvalidated and changed with no significant user impact, because ‘old’(expired or otherwise unwanted) tokens, either with active or expiredkeys, can be changed for new ones, at no security risk to the Mint.

In some example embodiments, a Mint may issue Value Tokens havingalternating characteristics. For example, a Mint may be limited to swapIntrinsic Value Tokens, only in return for Coded Value Tokens.

For example, given a set of intrinsic Value Tokens sent to the Mint, theMint can verify the validity of the Value Tokens, in this processinvalidating such Value Tokens and consequently issue a new set of CodedValue Tokens, to the same total denominations of the same Class as theValue Tokens it has received

Given a set of Coded Value Tokens sent to the Mint, the Mint can verifythe validity of such Value Tokens, in this process invalidating suchValue Tokens, and consequently issue a new set of Coded Value Tokens, tothe same total denominations of the same class as it has received

An advantage of this approach is that this provides a system embodimentwith sets of ‘alternating token properties’, where semi-anonymous tokenscan only ever be used for one step in a chain of transactions, as atleast every other transaction is fully identified.

This supports effective AML and other checks in a payment system thatdoes allow and support individual anonymous/untraceable transactions forthe payer.

In some example embodiments a Mint issuing Value Tokens may include oneor more sets of additional conditions, where such conditions may havebeen set by the Mint operator, the Issuer associated with the Mint, orother parties controlling the operation of the Mint or Issuer.

In some example embodiments a Mint can, when issuing Coded Value Tokens,encode in such tokens additional information, markers, and/or redemptionrules and/or the like. For example, a Coded Value Token may include arule ‘not for swap or exchange before date/time’.

Given a set of Coded Value Tokens sent to the Mint, the Mint can checkValue Tokens for compliance with encoded redemption rule information,and only in case of compliance proceed to verify the validity of theValue Tokens, in this process invalidating such Value Tokens andconsequently issue a new set of Intrinsic Value Tokens or Coded ValueTokens, to the same total denominations of the same Class as it hasreceived

This approach supports the capability of the system to have a network ofMints (and associated Issuers) in any arrangement, where each Mint inthe system has certain Value Token handling capabilities which aredescribed herein. In some example embodiments, Mints may retain a recordof Value Tokens that have been swapped or exchanged (spent). This may bereferred to as a Double Spending Repository. It will be appreciated thata double spending record may, may, but need not, be structured as alist, as such; rather any convenient data structure or storage mechanismmay be employed, e.g., any relational or non-relational databasestructure that facilitates high volume large scale secure transactionprocessing. Also, the Double Spending Repository may also includeadditional information regarding tokens that are invalid or tainted forother reasons, besides having been previously swapped or exchanged. Forexample, if for some reason a Mint key may be at risk of having beencompromised, the compromised Mint key may be marked as expired. Furtherswaps of such tokens may not be allowed to occur anonymously, allowingaudit trails to be maintained.

The Mint may also retain a record of all Value Tokens that it hassigned, whether or not they were signed using the Blind Signaturemechanism. It will be appreciated that valid tokens and redeemed orotherwise invalid or tainted tokens may be identified in the samerecords in a single repository or in separate records in a singlerepository, or in separate repositories.

Mint Operation

In some example embodiments, particular Mints may be limited to twooperations, Value Token initialisation and Value Token swap. Thislimitation for the Mint to these operations is well suited toinstantiation of Mints as devices and/or device elements where suchdevices and/or device element may receive messages across multiplemessage protocols and only on receiving a legitimate message (that is aValue Token) that was initialised (e.g., created and issued) by thatMint will the Mint respond with an operation. (In at least onealternative embodiment, Mints may issue tokens configured to be redeemedby a particular Mint or Mints other than the issuing Mint.) It may beadvantageous to have other messages received by the Mint but notcomplying simply be ignored, so that the attack surface of the Mint isminimized to only valid (to that Mint) instance messages.

Initialisation. This action creates Value Tokens to a given total ofdenominations, and encodes them to one particular party which is, oracts on behalf of, the Issuer.

An Issuer may be any party that is able to instantiate a Mint, wheresuch party instructs the Mint to create tokens of, and to the specifiedvalues. However, the underwriting of such Value Tokens may, in somecases, be constrained by assets provided by or assigned by an Issuer insupport of such Value Tokens. For example, an Issuer may create a Mint,however unless the Value Tokens created by the Mint have a recognizedinterchange capability, based on interoperable values the Issuer isoffering in return for the Value Tokens, their utility for exchange withother users may be extremely limited.

In some example embodiments, an Issuer operating a Mint may offer ValueTokens that are constrained to a specific domain, such as for example,reward points, school or college (or other organization specific) valuesand/or the like.

A Double Spending Repository may be limited to records involving oneparticular Mint Signature Key. A Mint Signature Key may be limited toone particular Class of tokens, and/or one particular Class/Denominationpair. A Mint Signature Key can be considered “Active” or “Expired”.

In some example embodiments, Mints may be implemented in hardware andmay incorporate one or more hardware based secure stores. Mints may beimplemented using secure capabilities of, for example Intel SGX, ARMTrustzone and/or other hardware processor based secure environments.

Multiple Security Levels and Key Expiry and Different Security Levelsfor Distinct Token Swap Messages.

In some example embodiments, a system approach to security may be basedon the nature of Value Tokens as electronic messages, because ValueTokens are single use instruments, they can securely be swapped by theMint only once. The Value Tokens are invalidated in the process of beingswapped by being added to the Double Spending Record.

Value Token swap message. This is the swap of Value Tokens of totaldenominations of (X) in a class, for new Value Tokens of equal totaldenominations (X) in the same class.

In some example embodiments, a Mint has a restricted set of Value TokenSwap operations that may be undertaken. These restricted operationsprovide an inherent security through reduced attack surface and limitedutility of these operations. In some example embodiments theseoperations can be differentiated and categorised in the following way:

Token Swap Message Type 1: A Payer is unknown through the use of BlindSignatures. A message where a Payee has obtained Value Tokens, and wantsto swap for a new set of Value Tokens known to the Payer only is passedto the Mint, which will only respond within these parameters.

Token Swap Message Type 2: A Payer is known and identified. A messagewhere the Payee has obtained Value Tokens from a Payer under full audittrail (e.g. not using Blind Signatures) such that the identity of thePayer is disclosed and where appropriate can be authenticated as such,and the Payer wants to swap the Value Tokens in the message for newValue Tokens. (For example this could include a message where the Issueritself acts as Payer).

Token Swap Message Type 3: A Payer is identified and is the same asPayee—This constitutes a Swap by one individual sending one set of ValueTokens, and requesting a new set of equal total denominations.

From a security perspective, Message Type 1 is the highest risk as theaudit trail available to the Mint is the lowest, Message Type 3 is thelowest risk because the audit trail available to the Mint is complete.This distinction of Token Swap message types and risk levels can then beused to implement the concept of Mint Key validity, expiry, swap, andexchange.

It is noted that the valid Mint signature keys are the most sensitivecomponent of the overall system, because they allow the creation of newValue Tokens. The time during which a Mint Key is valid, is also thetime an attacker has to attempt to break the key, and thus threaten thesystem by enabling themselves to create Value Tokens that the Mint wouldnot be able to distinguish from Value Tokens legitimately issued by theMint, during a Token Swap Message of types 1 or 2.

Mint keys may be time limited in validity, where such limitation maydepend on, for example the context of their use, for example insituations deemed to be high risk, by for example the Mint operator orIssuer, the time period may be set as short.

A further security feature, in our system is that expiry times (and/ortimestamps) for Mint keys may be based on arbitrary periods, (which insome example embodiments may be generated through use of, for example arandom number generator, where for example such generation may havefurther policies limiting the time periods involved, for example toexclude very short or very long times whilst ensuring such time periodsremain arbitrary). Mint Keys may be expired ‘on demand’ by the Mintoperator.

The approach described above makes the time window for any potentialattacker unpredictable, as well as allowing for immediate remedialaction (Mint key expiry) in the event of a higher perceived threatlevel.

Using the different categories of swap messages defined above, a systemwhere ‘key expiry’ has minimal direct user impact may be provided. Forexample, in some example embodiments, Mint Key expiry does not mean thatValue Tokens signed with an expired key are no longer accepted, butinstead limits the category of swap messages that they a Mint willaccept such Tokens for. Value Tokens issued under an expired Mint Keymay now only be swapped using Token Swap Messages of Type 3. Type 3messages also require the Payer/Payee to provide proof of withdrawal(for example the relevant blinded tokens and blinding factors and/orother Mint recognized indicia). This means that a full audit trail ofValue Token creation must exist in order for these Value Tokens to beswapped for new Value Tokens by the Mint. As a result, Value Tokensissued by an attacker after breaking the Mint key will be identified andnot swapped.

The resulting feature from a user's perspective is, that Value Tokensnever expire in the value they represent, what expires in the event of aMint Key expiry is solely the ability to use such Value Tokens for thirdparty transactions. A simple swap for new, current (and transactable)Value Tokens remedies any user impact, and this swap can even beachieved automatically without the need for user initiation.

The resulting feature from a system operator's perspective is, thatsystem security is enhanced, because the risk from a compromised Mintkey is limited to any exposure at the time of raised suspicion ordetection. After that, an ad-hoc key expiry action fully protects theMint operator from any further exposure.

In some example embodiments, an extension to this approach is a Mint‘Safe Mode’. In Safe Mode, only Token Swap Messages of Type 2 and Type 3are permitted (meaning blinded, anonymous transactions are no longerpermitted) as Mint operations. Such a Mint Safe Mode is an operationalremedy for potential major disruptions, for example if the employedpublic key encryption mechanism itself was broken and no longercryptographically safe. In this case, Safe Mode allows for continuationof systems operation (albeit limited through non-anonymity), until thesystem can be upgraded to operate with alternative public keycryptography.

Alternating Value Token Properties

In some example embodiments, one difference between Intrinsic ValueTokens, and Coded Value Tokens, is that only the former type is issuedusing Blind Signatures in support of anonymous transfers. Coded ValueTokens are always issued for transfer with an audit trail, as well ashaving the option to carry additional information sets, such as Tokenattributes described herein.

In some example embodiments, in Token Swap Message 1, Intrinsic ValueTokens are only swapped for Coded Value Tokens.

Token Swap Messages 2 or 3 allow Coded Value Tokens (obtained with fullaudit trail or under a Token Swap Message 1), to be swapped for eitherIntrinsic or Coded Value Tokens. Accordingly, after every anonymoustransaction under a Token Swap Message 1, there is always at least onenon-anonymous transaction under Messages 2 or 3.

Such an approach supports enforcement of policies, rules, conditionsand/or the like, associated with, including attached to circulation ofvalue in the system. This cannot be implemented in Chaum based anonymousprotocols (Message Type 1) system only. Such an approach supports AMLand other similar regulatory obligations, while retaining payer privacycomparable to a Chaum based system.

Token Re-Circulation Limits

As described herein, Value Tokens may have an expiry date/timeassociated with them, and/or may have a ‘not valid before’ timestampassociated with them. Such timestamps may be associated in anycombination.

In some example embodiments, such an optional ‘not valid before’timestamp for Value Tokens, may be included in order to implement ‘speedlimits’ on circulation and re-circulation of value in the system.

Fast re-circulation of Value Tokens inherently poses higher risks to asystem, particularly in the Internet environment or other applicationswhere there are an extremely large number of distributed users. Fraudrisk is increased even in transactions with full audit trail, if it ispossible to achieve several re-circulation transactions to differentparties within a short period of time. Some monetary policyconsiderations also rely on limited re-circulation speeds of monetaryvalue as fast re-circulation is seen to carry potential for de-factoinflation.

In some example embodiments, the provision of ‘not valid before’timestamps on individual Value Tokens (and/or sets thereof) supports theintroduction and management of re-circulation limits, including to thelevel of individual participants, for example, users, or wallet owners,as well as speed controls to the level of individual transactions,and/or individual Value Tokens.

This supports one or more categorisation schemas for individual users,and/or individual transactions and/or transaction types, and applicationof different re-circulation limits depending on such characteristicsand/or system conditions.

For example, users satisfying one or more higher identification and/ortrust requirements may be permitted faster re-circulation of value.Users and/or transaction sets identified as higher risk, for examplethrough profiling of transaction data, may trigger extendedre-circulation limits.

Generally, these sort of rules are potentially more difficult toimplement in a ledger based system.

Extensions to Double Spending Record

In previous Value Token based systems (for example DigiCash, eCash), thepurpose of a Double Spending list was to identify which Value Tokenshave been swapped, and are hence invalidated as ‘spent’. A Value Tokenis either not on this record, or it is, in which case its status isconsidered ‘spent’.

In contrast operation of the Double Spending Record described in thepresent disclosure may have an extended purpose, by introducing otherpotential status parameters for Value Tokens beyond binary ‘spent’/‘notspent’.

In some example embodiments, a Value Token may be considered to be‘suspect’, or ‘tainted’, if it has been involved in a transaction thatfailed. For example, if a payment message contains a mixture of ValueTokens that appear valid (not spent), and some that appear spent, thenthe whole transaction can be rejected, but all Value Tokens thatappeared valid may be added to the Double Spending Record as ‘tainted’.

In this example, a limitation or constraint may be applied to theacceptance of such tainted Value Tokens to Type 3 Swap Messages, meaningthe owner has to identify themselves under proof of withdrawal, in orderto swap for new Value Tokens. Alternatively, we may use tainted ValueTokens for passive monitoring for potential user fraud and attacks only.

In some example embodiments, the purpose of the Double Spending Recordis expanded, by introducing other potential status parameters for ValueTokens beyond simply the binary (for example ‘spent’). Such multi valuerecords can support several operational parameters to be varied, as wellas the implementation of multiple rule sets in response to differingevents, alters and/or other messages and conditions associated with aValue Token sets (and/or those associated with such set). For example, afurther parameter value for the Double Spending Record may be ‘underESCROW’. This parameter is used in the implementation of our Value TokenExchange facility discussed later in the present disclosure.

Example Value Token Ecosystem

FIG. 1 illustrates an example digital Value Token ecosystem, accordingto an example embodiment of the present invention. In this ecosystem,payments between users may be provided using a message based paymentcapability employ digital Value Tokens. Some example embodimentsdescribed herein provide a set of services for such message basedpayments, as well as for various ancillary processes to support such apayment infrastructure.

In the example embodiment, a user of the system may send to another userof the system one or more messages comprising a set of Value Tokens of aspecific Class. This creates a situation where if the message wereintercepted in transit, or copied by another party who is not theintended recipient, then only the valid recipient can create a swapmessage at the appropriate Mint.

Users 110 may include individual natural persons, organizations, orintelligent software agents acting on behalf of a natural person ororganization. Both users may both register with and validated by asystem registration service. Each user 110 may have an associated device112, e.g., a computer, mobile phone, or other device. Each device 112has a respective digital wallet 114 stored on the device. The walletsare cryptographically bound to their respective users and registeredwith a system registration service. It will be appreciated that aparticular device may support multiple wallets with multiple classesand/or class equivalents; the leftmost device is shown with two wallets.The digital wallets 114 may store Value Tokens belonging to the user 110of the device 112.

It will be appreciated that, one or more users may be associated to asingle wallet, for example cryptographically bound using digitalcertificates. Conversely one or more wallets may be similarly bound to asingle user. In both cases such a user may be identified with a validpersistent network address or identity, for example those issued by oneor more independent network services, such as email providers,individual bank accounts, mobile phone numbers, social networks (e.g.Facebook) ID's, message systems (e.g. Twitter) IDs and/or other servicesunder the control of the user.

The degree to which such an identity may be verified and authenticatedmay, in some cases, determine the degree to which such an identity ismanaged and/or interacted with by one or more system elements.

User identity registration may be undertaken by a service that storesthe identity of the user such that other users may be able to look upsuch an identity by querying such a user registration service. In someexample embodiments such a service may create directly or through adelegated proxy a wallet for that user identity such that the useridentity is cryptographically bound to that wallet instance.

Such a wallet instance may be instantiated as software and/or hardwareelement and may be located on a computing arrangement, storage medium,device, cloud service and/or any other suitable environment. Forexample, such a wallet may be instantiated as a secure environment, suchas a sandbox, container or other secured memory or processingenvironment, for example such as those supported by ARM TrustZone orIntel SGX enclaves.

The example system may further include one or more merchants 130, withtheir own respective devices 132, e.g., servers that provide interfacesfor selling goods or services via the Internet or in the physical retailworld. These merchants may have their own wallets 134 for storingdigital Value Tokens received as payments for goods and services.

The example system may also include one or more Mints 140. The Mints areconfigured to issue and swap digital Value Tokens received from users(who may be associated with merchants). Optionally, the Mints may alsobe configured to facilitate exchanges of Value Tokens of differentClasses. In some example embodiments, specific functionality, such asMints, may be embodied in chips, such as FPGAs, so as to provide asecure distributed system where processing systems of the user, such asfor example their cell phone, laptop, smartcard and/or other devicebecomes an effective secure system element using associated messaging,cryptography and communications methods.

The example system may also include one or more Issuers 150. Each Mintmay have an associated Issuer 150 (which may or may not be shared,depending on the situation). The Issuers may serve as a repository forthe assets underpinning any Value Tokens and the Mint which isresponsible for the issuing and swapping of these Tokens. The separationof Issuers and Mints may make possible the issuing and swapping of ValueTokens independent of the assets that underpin such Value Tokens. Forexample, an Issuer may provide a set of assets, in the form ofsecurities or other tradable commodities (including sovereign legaltender), which may then form the collateral for an Issuer supportingthat Mint's issuing of Value Tokens, for example as Value Tokens with afixed denomination (intrinsic Value Tokens further explained herein),where the total value of the assets held by the Issuer can be dividedinto these specified denominations.

The merchants and users and Mints may be connected via a network 120,e.g., the Internet or other network. The messaging systems employed forthe communication for the messages may include, for example email, SMS,NFC, Barcodes, messaging applications (e.g. Whatsapp), messagingplatforms (e.g. Skype), social networks (e.g. Facebook) and/or any othercommunications medium capable of supporting messages, and may operateeven using messages of less than 1 kilobyte in size.

The system may also include escrow services 170, that provide escrow tofacilitate exchange of various types of tokens between users, e.g., in alower risk transaction where token exchanges are “pre-cleared” by havingeach side place a digital Value Token into escrow before the transactionis completed. The escrow services may be provided by Mints, or may beprovided by separate elements that are in communication with the Mints.

FIG. 2 illustrates a token swap, according to an example embodiment ofthe present invention. A requester (which may be a device acting undercontrol of or on behalf of user) sends a message to a Mint. Included inor with the message are a token or tokens for which a swap is beingrequested. The Mint receives and validates the Value Tokens, andassuming the Value Tokens have been validated, it signs new Value Tokenswith a Mint key, which may be stored in a hardware keystore, such as asecure memory. The tokens, and possibly additional messaging are thenreturned to the requester. Various types of Swaps and Value Tokens areused to implement example procedures, as previously described in thisdisclosure. For example, Swaps are part of example payment proceduresdescribed in this disclosure.

FIG. 3 illustrates an example payment, according to an exampleembodiment of the present invention, e.g., a payment made in the contextof the payment ecosystem described above in FIG. 1 . FIG. 4 illustratesthe same transaction in a timeline form with each column representingone actor in the transaction. User 1 has an intrinsic digital ValueToken stored in a digital wallet, e.g., on a Device 1 (D1) controlled byUser 1 (U1). User 2 (U2) may be identified by U1 with a variety ofapproaches, e.g., email, phone identity or other identity indicia whichare recognized by a system identity registration service. When User 1wishes to send User 2 some value, e.g., a payment, the transfer may bemade with one or more digital Value Tokens in one or more denominations.User 1 may instruct D1 to make the payment to U2 and selects the value,by denomination or by value of the transfer to User 1. D1 then sends theat least one intrinsic digital Value Token to User 2, e.g., by havingmessage include the digital Value Token sent from Device 1 to a Device 2controlled by User 2. For example, such interaction may be supported bybluetooth communications, NFC and/or other peer to peer communicationsmeans, including for example displaying of a bar code (such as a QRcode) which may then be photographed by User 2 with their Device 2.Responsive to receiving the digital Value Token, Device 2 then sends aswap request, including the digital Value Token to an appropriate amint, e.g., a Mint that is identified in the digital Value Token asbeing the Mint which accepts that particular digital Value Token. TheMint then validates the digital Value Token, e.g., by confirming it hasnot been previously redeemed, and sends in return a coded digital ValueToken to Device 2, where it may be stored in User 2's digital wallet.

While it is not illustrated in the FIG. 3 , and not always required, itwill be appreciated that other actions may also occur incident to orancillary with the illustrated payment, e.g., Device 2 might issue areceipt for the payment to Device 1 in response to receiving the codedValue Token from the Mint. It will also be appreciated that the paymentmight be made in any context, as a gift, as a payment for services to berendered, in satisfaction of an invoice or request for payment, etc.Moreover, subsequent to receiving the coded Value Tokens, User 2 mightrequest a swap of these tokens from the Mint, in order to receiveintrinsic Value Tokens in return for them. This might be undertakenautomatically as part of the features provided by a digital wallet.

FIG. 5 illustrates an example digital Value Token Swap procedure in moredetail, according to an example embodiment of the present invention. Theexample procedure may be carried out by a Mint. The Mint may be providedin software and/or in hardware, but as part of the process will need todigitally sign newly issued Tokens. Accordingly, the Mint willpreferably have some sort of a secure mechanism for holding a Mint keyto sign newly issued tokens, e.g., in a secure hardware device or securememory.

In 510, one or more previously issued Value Tokens may be received,e.g., by a Mint. It will be appreciated that, while one or morepreviously issued Value Tokens may be sent for Swap in a singletransaction, the example procedure is described here in terms of asingle Token for simplicity. Multiple Tokens might be swapped in asingle atomic transaction, or in separate transactions, althoughpreferably tokens swapped in a single atomic transaction would all be ofthe same Class. The shared Class might represent a sovereign currency, asecurity, a commodity, or even simply another Class of digital ValueToken. Depending on how the redemption protocol and Mints areconfigured, the Value Token may be received as part of a request to Swapthe Value Tokens, e.g., as part of or an attachment to a Token Swaprequest message. Alternatively, a Mint may be configured to attempt toswap the previously issued Value Token automatically upon receipt of theValue Token. The Value Token may be of a particular Class and may eachinclude a respective digital signature and, in the case of a coded ValueToken, other information, such as denomination.

Optionally, as part of the Token Swap request, newly issued Value Tokensmay be received, e.g., from the party requesting the Token Swap. Atleast with respect to Mint issuing the Value Tokens, the tokens areunsigned (by the Mint). However, in some example, these unsigned“proto-tokens” may be signed using a blind signature protocol like theChaum blind signature protocol. As part of processing the Token Swaprequest, the Mint may verify that the proto tokens are authentic. Usingthis protocol, it is possible that the tokens do not later identify therequester when being returned in a future Swap request.

In 520, it may be determined if the previously issued Value Tokenreceived to be swapped is an Intrinsic or Coded Token. If the previouslyissued Value Token is Coded, the example procedure may continue with530. If the Value Token is determined to be Intrinsic in 520, theexample procedure may continue with 550. It will be appreciated that,even if the Value Token presented for Swap is validated, in the exampleprocedure, only Coded Tokens are issues in Swap for Intrinsic Tokens,whereas, Coded or Intrinsic Tokens can be issued as Swaps for CodedTokens. A received Token Swap Message for a Coded Token may indicatewhether Coded or Intrinsic Tokens are desired, and may accordinglyinclude proto Tokens under a blind signature protocol.

In 530, the Coded Value Token may be validated. First, the signature ofthe previously issued Token may be validated, e.g., by decrypting thedigital signature. In 532, the validity of the Token may be confirmed bychecking the status of the Token in a data repository to confirm thestatus of the Token, e.g., confirming the Token has not been previouslyswapped by checking information on previously swapped tokens which areno longer valid, or that the Token is not invalid for some other reasonnoted in the data repository. In 534, the Token swap rules may bechecked. For example, redemption rules might include rules about when aToken should be redeemed, or what Mint it should be redeemed at, orother rules. The swap rules might include an identifier of a swap Mintfor the Token, and if the Mint receiving the Swap request is not theswap Mint, the request to swap might be rejected, or alternatively mightbe re-routed to the appropriate Mint. The swap rules might also includetimes before which or after which the Value Token is valid, a geographicidentifier indicating a geographic area where the Value Token is valid,jurisdictions where the Value Token is valid, and/or other attributes.There may also be multiple factors which are used to create a riskprofile of the Value Token, and to deny swaps requests for tokens havinga risk profile of, for example, at least a certain level or value, or toinstead deny anonymous swap requests for tokens have a risk profile overa certain level/value and/or that meet one or more specified criteria.

In 536, if any of the required checks of the Token set are notsatisfied, the procedure proceeds to 538, where the attempt to obtain aToken Swap fails. An appropriate message may be sent to the user deviceattempting to swap the Token set, perhaps including information aboutwhy the Token set has not been swapped. In some cases, if the redemptionrules indicated a new intrinsic Value Token should not be issued,because of various risk factors, the requester might resubmit therequest to swap the coded Value Token for a new coded Value Token,rather than swapping for an intrinsic Value Token.

If the validation of the Token set is successful, the procedure proceedsto 540. In 540, the type of Token set requested is determined, e.g., byinformation received in the Token Swap request message. If a Coded Tokenis requested, in 542 a newly signed Coded Token, signed with the Mint'sdigital signature, will be issued, e.g., by sending it to the devicethat requested the Token Swap. If an Intrinsic Token is requested, in544, a newly signed Intrinsic Token, signed with the Mint's digitalsignature, will be issued, e.g., by sending the newly signed Token tothe device that requested the Token Swap. In either case, the new Tokenset will have the same Class and may have the same, or nearly the sametotal denomination as the old set of tokens. It will be appreciatedthat, in some cases a transaction fee or other modification may causethe value not to be completely identical.

In an alternative approach, the denomination of an issued token ortokens may itself be a function of, rather than merely equal to thetotal of the denomination of the incoming set of Value Tokens. Forexample, interest type scenarios, intentionally inflationary ordeflationary currencies, where, for example, each Swap increases ordecreases the amount of a token. In one alternative, this function mayinclude other information, such as the elapsed time since the issuanceof the Value Token, to allow the function to depend on time, rather thanmerely number of swaps. In another example, a function may be applied tothe total denomination of the previously issued Value Tokens beingswapped relative to the total denomination of the newly issued ValueTokens being created, for example to permit subtraction of implied feesin transaction processing.

It will also be appreciated, that while single tokens may swapped forsingle tokens, atomic transactions allowing the swaps of sets of tokensfor a single token having the same total denomination or for a sets oftokens having equal total denominations in a single atomic transactionmay also be provided. In addition, other forms of swaps may also beprovided. For example, the value of a single token might be split intomultiple tokens.

In 550, the intrinsic Value Token to be swapped may be validated. Thenature of the validation depends on the state of the signature key whichthe Value Token was signed with. If the signature key is expired, theprocedure continues with 552, where more extensive token validation isdone. It will be appreciated that other tests may also cause theprocedure to route to more extensive validation, e.g., some sort oftaint associated with the particular token. If the signature key isactive the example procedure continues with 570, where token validationmay be less extensive. In some variants, conditioned on any of therespective token signature key expiration states being expired and therequester being a party other than an original requester who receivedthe Value token when it was issued, a request to swap the previouslyissued Value Token may be refused. In one alternative embodiment, if theValue Token signature key expiration state is expired, and the requesteris the original requester who received the previously issued Value Tokenwhen it was issued, the swap request might be accepted, assuming otherforms of validations being used are also successful.

In 552, if the signature of the swapped token is expired, the signatureis validated in 552, e.g., by decrypting the digital signature. In 554,the validity of the Value Token may be confirmed by checking the statusof the Value Token in a data repository to confirm the status of theValue Token, e.g., confirming the Value Token has not been previouslyswapped by checking information on previously swapped tokens which areno longer valid or that the Value Token is not invalid for some otherreason noted in the data repository.

In 556, ownership related checks for the Value Token may be made. Forexample, the identity of the requester of the swap may be checked. Insome variants, the Value Token includes a digital signature of theoriginal recipient, which may be a random blinding factor under a blindsignature protocol. This signature may be validated to verify the ValueToken's ownership. In 560, if any of the preceding validity checks forthe Value Token and requested swap have failed, the procedure mayproceed to 562, otherwise it may continue with 576.

In 562, the request to swap the intrinsic Value Token fails. Anappropriate message may be sent indicating the reason for the failure tothe device or user requesting the Value Token swap.

In 570, a token whose signature is active may be validated. The tokensignature may be validated, e.g., by decrypting the digital signature.In 572, the validity of the Value Token may be confirmed by checking thestatus of the Value Token in a data repository, e.g., confirming theValue Token has not been previously swapped by checking information onpreviously swapped tokens which are no longer valid or that the ValueToken is not invalid for some other reason noted in the data repository.In 574, assuming the validity checks for the Value Token and token swaprequest have not all be successful, the procedure may continue with 562.Otherwise the procedure may continue with 576. It will be appreciatedthat, in some variants, for unexpired tokens request to swap apreviously issued Value Token might be handled independent of theidentity of the requester.

In 576, an intrinsic Value Token has been successfully validated forswap. An invalidity record, such as a double spending repository may beupdated to reflect the swapped token is no longer valid, e.g., byindicating it has already been redeemed. In 578, a newly signed codedValue Token may be issued, e.g., by signing it with the digitalsignature of the Mint and sending it as part of a message to the devicethat requested the Value Token swap.

Example Token Issuance

FIG. 6 illustrates in more detail elements of the issuance of new codedValue Tokens, corresponding to element 542 or 578 in FIG. 5 . When newlyissued Value Tokens are created and issued in return for a swap message,the recipient is identified to ensure that the right person isrequesting and receiving the newly issued Value Tokens. In 610, a Mintmay create proto tokens or receive proto tokens for signing. Optionally,a Mint may verify the identity of the requester, e.g., by receiving orrequesting a digital signature or other authenticated identityrepresentation of the requester. In 620 the Value Tokens may becertified as authentic by the mint, e.g., signed by the Mint issuing theValue Token, using a securely held secret active Mint key and aconventional digital signature protocol. In 630, information about theValue Tokens may be entered into a record for the Value Token in a datarepository storing information including information related to validtokens. This data repository may be structured as a secure file, securerelational database, or other form of data storage. The data repositorymay be included as part of a Mint device, or may be in a locationaccessible to the Mint issuing the Value Tokens. It will be appreciatedthat multiple mints may possibly share the same data repository, andthat the repository may be in a distributed form, such as a distributeddatabase. The information included in the data repository for a codedValue Token may include, for example, identity of the Mint issuing theValue Token, class and denomination of the Value Token, time the ValueToken was issued, and identity of the recipient of the newly issuedValue Token and/or any other token related information sets, includingfor example any information sets pertaining the risk profile/value ofsuch a token, the relationship of one set of tokens to another (forexample multiple sets from a single user) and/or the like.

FIG. 7 illustrates in more detail elements of the issuance of newintrinsic Value Tokens, corresponding to element 544 in FIG. 5 . In 710,new proto tokens may be received, or created for signing. The tokensmight be blinded and/or securely bound to a requester, e.g., using aChaum blind signature. The adequacy or correctness of the proto tokens,including their denominations, may be verified in 720. In 730 the ValueTokens may be certified by the Mint, e.g., by digitally signing themusing Mint active private Mint key. The parameters of the intrinsicValue Tokens that are created are set by the signing of the Value Tokenswith one particular signature key. This signature key itself isassociated with one specific set of intrinsic Value Token parameters,such as the class of token, and the denomination, or any otherparameters applicable to the intrinsic Value Token.

Example Mint Architecture

FIG. 8 illustrates an example architecture for a mint, according to anexample embodiment of the present invention. The Mint 800 may beprovided in hardware and/or software, e.g., as a custom or semi-customdevice, an appliance or device, a hardware component (for example aSystem on a Chip and/or an FPGA), on a dedicated computer, and/or as aservice (for example as Software as a service) provided for example in avirtual system and/or cloud arrangement. The Mint may be configured toperform the token swap and token issuance processes described in thepresent disclosure. It will be appreciated that various elements of theMint 800 may be separate hardware elements, software modules, orservices/functions provided by a single Mint service.

For example, an embodiment of a Mint in hardware, for example using aSOC (system on a chip) approach such as an ARM chip with thecryptographic functions operating in the secure section, may be embodiedin multiple devices and/or may be instantiated in, for example an FPGAwhich may connect to a secure cloud service for key management and otherservices.

A controller 810, may be a computer processor, which controls theoperation of the mint, e.g., under software control. The other elementsof the Mint may be separate hardware elements, software modules, or acombination thereof. In some embodiments, there may be a rules module,operating under the control of the processor configured to determine therules associated with an “old” or previously issued Value Token, e.g.,based on information in or about the previously issued Value Token, andto allow token swaps to occur only when they are in compliance with therules.

A swap interface unit 820 may be configured to receive a request, e.g.,a network message, from a requester seeking to swap a previously issuedValue Token. The previously issued Value Token to be swapped may also bereceived as part of, attached to, or in conjunction with the request toswap. The received request may indicate the type of token beingrequested to be received. The received previously issued Value Token mayhave a class, a digital signature (or more than one digital signature),and a denomination. In some embodiments such an interface unit mayimplemented for example as swap appliance which may receive and processswap messages for validation, verification and routing. This may includea specialized hardware component, which when combined with theappropriate network communications capability may undertake suchprocessing and routing.

The controller may cause the Value Token's validity to be verified by atoken verification unit 830, which may receive the Value Token from theswap interface unit. Separate verification subunits may be provided forintrinsic and coded Value Tokens, respectively 832 and 833. These unitsmay, e.g., implement the verification procedures described elsewhere inthe present disclosure. The intrinsic Value Token verification unit 832may be in communication with a Spent Token data repository 840, whichmaintains information on tokens that have already been swapped, in orderto prevent double redemptions. This data repository may be in any secureform and is not limited to a particular approach to data structure orstorage. e.g., a secure relational database. The intrinsic Value Tokenverification unit may also be in communication with a repository storingblinded signed proto-tokens 836. Archived token public keys may bestored in a data repository 838, which may be contained in the mint, orat some other location. For example, such a repository may also includeone or more sets of parameters associated with such public keys. Thisinformation may be used to verify digital signatures on tokens presentedfor redemption when they are being verified by the token verificationunit 830.

The coded Value Token verification unit 833 may be in communication withan archived public key repository 834 and a valid token repository 835that are used to verify coded Value Tokens.

A token certification unit 850 may be used by the Mint to certify newlyissued tokens. The certification unit may have access to the mintscurrent private token signature keys stored in 870, which are used tosign certified tokens. 870 may include a secure process and/or securememory that is used to securely store the Mint's private keys.

The intrinsic Value Token certification unit 852 may have access to therepository 836 for blinded signed tokens, for example to storeinformation for subsequent evaluation. The coded Value Tokencertification unit 854 may have write access to the valid tokenrepository 835, in order to update information regarding valid codedValue Tokens, such as for example when these tokens are certified.

Optionally, the Mint may also include or have access to an escrow unit880, that may be employed to pre-clear swap or exchange transactions,for example, in token exchanges. The escrow unit may have access to thevalid token data repository 835 and or the spent token data repository840 in order to check and update the status of tokens during the escrowprocess.

FIG. 9 illustrates an example token data repository, according to anexample embodiment of the present invention. While the data isillustrated as a table, it will be appreciated that any form of datastructure or storage may be employed.

Example Coded Value Token

FIG. 10 illustrates an example coded Value Token, according to anexample embodiment of the present invention. The coded Value Token isstored, e.g., in the digital wallet of a user, or at a Mint. It will beappreciated that the coded Value Token is presented to illustrateexample information that may be associated with a coded digital ValueToken, and not all of the features shown must be included in every codedValue Token. Except for some form of identifier, the associatedinformation need not actually be contained in the Value Token, butrather could be stored in a repository and linked to the Value Token,e.g., by using the identifier as an index. Moreover, it will beappreciated that, while the data is shown in FIG. 10 is provided forillustration purposes, any suitable data structure may be employed, andportions or the entirety of the information included may be coded and/orencrypted in a variety of ways.

The example coded Value Token may contain a variety of information. Someor all of the information may be expressed as a cryptographically signedcertificate set in the Value Token. The token may contain 1010 a uniqueidentifier, e.g., a string, a number, a sequence of bits, or any otherconvenient format. The Value Token may contain a unique identifier ofthe Mint 1020 that issued the value token. The Value Token may containan indication of the class of the Value Token 1030. In the example theclass is “Euros”, showing the value token represents sovereign currencyin Euros. The Value Token may contain a denomination value 1040, in thiscase 10 Euros. The Value Token may contain temporal information 1050,such as a “not valid before” indicator or a “not valid after” indicator.The Value Token may include redemption rule information 1060, possiblyjust a parameter for pre-coded redemption rules, or identifiers ofpre-identified redemption rules, e.g., rules available at the Mint,which created or is designated to redeem the Value Token, or parametricinformation used for rules associated with particular classes of tokens.In an alternative, the Value Token might even include coded informationthat allows determination of the rules themselves. The Value Token mayinclude a risk indicator 1070. Here the risk indicator is “None”indicating no special risk associated with the Value Token, but variousother risk states, “tainted”, or more particular status information, ornumerical risk levels may be provided.

Mint Initialization

FIG. 11 illustrates an example Mint initialization, according to anexample embodiment of the present invention. A Mint may be created by oron behalf of an Issuer which wishes to issue and swap tokens in aparticular class. The Mint may configure and employ secure hardware forsecret key management, e.g., ARM Trustzone/Intel SGX or otherspecialized secure, including tamper resistant, hardware.

In 1110, a new Mint instance may be created, e.g., by activating adevice and/or software that serves as a mint. The new Mint may becreated by an Issuer. The software may run on secure hardware thatprovides for secret key management. In 1120, the Issuer may requestverification of the Mint instance from a certification authority. Thisverification may include checking the certification of the Issuercreating the mint. In 1130, the certification authority verifies theMint instance and may sign the Mint instance, e.g., using conventionaldigital signature/certification approaches. In some cases, the Issueritself may also be certified by a CA and/or may be securely bound to theMint. It will be appreciated that, in alternative approachescertification of the Mint or the Issuer may not be required orundertaken.

In 1140, the Mint is authorized to create a token set, e.g., aparticular total denomination of tokens of a particular class, or atotal number of tokens of the particular class of fixed denomination.The authorization may be given by the Issuer and/or the certificationauthority at the request of the Issuer. The Mint may also create orreceive the first active signature key. In 1150, using this key, theMint may create the first set of valid tokens. This set of tokens may beall or part of the defined total denomination of all tokens forcirculation by this mint of which are authorized by the Issuer.

The initial batch of tokens may then be deposited with the Issuer by theMint. In 1160, the Issuer may provide the Mint with tokens that areapproved by the Issuer for issuance, for example an unissued token setsigned by the Issuer may be received, and then signed by the Mint uponissuance. In 1170, the Mint may interact with users, provided tokenswaps or exchanges as described previously in this disclosure.

The Mint may undertake certain key management operations, including forexample, expiring of signature keys and creating new ones as directed.The Mint may also increase the total denomination of all tokens incirculation, that is minting newly issued Value Tokens outside of swapmessages. This may be undertaken at the behest of and under direction ofthe associated Issuer, e.g., using a procedure similar to theinitialization procedure illustrated in FIG. 11

Networks of Mints

In some example embodiments, several instances of Mints can interact ina cooperating fashion, e.g., as a Network of Mints. Two types ofNetworks of Mints, to address two different aspects of scalability aredescribed below.

Network of Mints Issuing Single Class of Value Tokens

In a first form of Mint Networking, a set of Mints can be networked sothat multiple Mints can issue the same single Class of Value Token. Thissolution is used to allow for scalability of electronic cash protocols,in particular the Blind Signature protocols, and overcome the knownlimitations of these protocols, in particular, the bottleneck of thedouble spending record. A new approach to overcoming this bottleneckthrough the networking of Mints under a specific protocol is outlinedherein, which effectively solves this issue through specialised loadbalancing.

In this embodiment of a Network of Mints, each Mint issuing the sameClass of Value Tokens is designated a specialised Mint ID within theNetwork of Mints. Each Mint now uses a set of active Value Tokensignature keys, so that each key relates to a combination of(denomination, Destination Mint ID), when issuing Value Tokens of thesame Class.

A Value Token of the relevant Class is now exclusively available forswapping at the Mint with the ID equal to the Destination Mint IDspecified in the Value Token. This Mint may be, but need not be, thesame Mint in the Network as the Mint that issued the relevant ValueToken in the first instance.

For verification of the received Value Tokens in a Swap Message, theDestination Mint now requires (a) the relevant public key setcorresponding to the originally issuing Mint's signature key, and (b)its local Double Spending Record, which is now a Record for each issuingMint in the Network. We specifically note that the signature key is notrequired for this verification, only its corresponding public key.

In this alternative:

-   -   Verification against double spending is no longer required to be        done by the issuing Mint, nor indeed by a single verification        point.    -   The distribution of the double spending check allows both        (theoretically) unlimited scaling of the double spending check        free of a single bottleneck, as well as load balancing between        Mints within the Network, without compromising the unambiguous        state verification of individual Value Tokens.    -   New and additional Mints can be added to the Network so that        scaling can be undertaken dynamically, by adding capacity to an        operating Network of Mints, as required. Accordingly, if a        specific Mint instance load is evaluated as being too high (or        is predicted to be too high in the future), then such an        instance may be replicated so as to provide a load balancing        arrangement which is transparent to a user.

Network of Mints Issuing Different Classes of Value Tokens

In a second form of Mint Networking, a set of Mints issuing differentClasses of Value Tokens may be networked through an additional systemcomponent, which we refer to as an “Exchange”. The Exchange facilitatesusers exchanging, or trading, Value Tokens of different Classes. In aparticular embodiment, the Exchange achieves the operation of a platformfor the trading of Value Tokens, with greatly reduced systemic risk. Wenote that this is a significant improvement over commonly operatingexchange trading systems, which are generally net settlement based.

The exchange trading process may be facilitated within ESCROW state ofthe Value Tokens at participating Mints, which may be provided as anextension of the Double Spending Repository previously described in thisdisclosure.

Exchanges may be provided, e.g., by an escrow unit included in oraccessible to particular Mints, or by a separate subsystem providingsimilar capabilities. An Exchange may offer users the facility to placeorders for an exchange trade, by providing to the Exchange the ValueTokens to be exchanged, and by specifying the class and denomination ofValue Tokens they are to be exchanged for. (Alternatively the specificvalue tokens to be exchanged for might be identified by either party.)To complete placement of such an order, the Exchange will submit theValue Tokens being submitted for exchange to the relevant Mint, whichmarks them as ‘under ESCROW with Exchange X’ in its Double SpendingRepository. This means that the relevant Mint will no longer permitspending of the Value Tokens so marked, except for a transactioninvolving the Exchange X, which can be (a) a successful trade matched byExchange X, or (b) a cancellation of the order.

In the event of the Exchange receiving a matching order, this order toowill include the Value Tokens submitted for trading. Consequently, theaction of matching the orders and executing the trade is in fact anexchange of the two sets of Value Tokens between the two users whoseorders are being matched. This is then achieved by each user receivingthe corresponding Value Tokens of the other user involved in this trade,then submitting them to the issuing Mint in a Token Swap message, inorder to obtain new Value Tokens of the desired Class.

The result is that at the end of this trade transaction, bothparticipating users have successfully exchanged valid Value Tokens ofone Class, for Value Tokens of the desired other Class. In the process,this transaction has become fully settled and finalized through theholding on new Value Tokens by each of the two users, such that nofurther separate clearing or settlement is necessary.

One could conceptually consider trades in this Exchange to be‘pre-settled’, in that because order placement on the Exchange includessubmission of valid Value Tokens itself, conceptually the exchange ofvalid Value Tokens of different Classes in itself comprises a finalized,fully settled, exchange trade.

For example, user A submits Value Tokens of Class A, issued by Mint A,(of total denomination n), to the Exchange X, and specifies that inreturn, he wants Value Tokens of Class B, issued by Mint B, (totaldenomination m). We consider this the order placement. Exchange X nowvalidates the Value Tokens included in the order, by sending them toMint A for a Mint ESCROW submission. They are confirmed valid by Mint A,which annotates them as ‘under ESCROW for Exchange X’ in the appropriateDouble Spending Record. The order is listed by Exchange X as availablefor matching trade.

After some time, user B submits an order, which includes Value TokensClass B, (total denomination m), and requests in return Value TokensClass A (total denomination n). This order matches the order by user A.Exchange X now matches the orders and executes the trade, by sending theValue Tokens Class B (total denomination m) to user A, and the ValueTokens Class A (total denomination n) to user B. In this example, thisis achieved through a Value Token Trade message, which includes theauthorisation by Exchange X to the relevant Mint, to release therelevant Value Tokens from ESCROW (essentially permitting the Mint tomove their status to ‘spent’ in the Double Spending Record, in thefollowing Swap message). User A now sends the Value Tokens Class B hereceived to Mint B in a Swap message, thus obtaining new valid ValueTokens Class B, and user B sends the Value Tokens Class A he received toMint A in a Swap message, thus obtaining new valid Value Tokens Class A.This set of messages has now achieved a fully settled trade betweenusers A and B. The net effect of this approach is that exchangetransactions are essentially pre-cleared, and settled in real time. Thisis achieved by using a combination of two Token Swap messages, togetherwith the system attributes described herein.

In an alternative approach, the Exchange may itself deposit the ValueTokens received in an order with the relevant Mint in a Swap message,thus obtaining new Value Tokens, and hold these new Value Tokens itselfduring the period when an order is active. In the event of a matchingorder, these new Value Tokens are then sent to the corresponding partiesin a trade, who in turn obtain new Value Tokens through Swap messageswith the relevant Mints. This approach does not make use of the specialESCROW state in the Mints' Double Spending Records, but it increases thelevel of trust required in the Exchange by the users.

In some embodiments, partial order matching will be permitted, andfacilitated by the Exchange through the exchange of a subset of ValueTokens included in a particular order, and, if necessary, the swappingof Value Tokens with participating Mints for Value Tokens of differentdenominations required for the partial matching of an order.

In some embodiments, the Exchange may send Value Tokens being exchangeddirectly to the relevant Mints on behalf of the users involved in atrade, and obtain new Value Tokens for each user in that trade, thensend those Value Tokens to the users for settlement. The users may theneach optionally swap those Value Tokens with the relevant Mints again,thus obtaining new valid Value Tokens.

In some embodiments, the Exchange may provide for a message protocolthat explicitly ensures the full completion of a trade including thereceipt of new Value Tokens by each user involved in a trade, oreffectively ‘rolls back’ such a transaction in the event some componentsof it do not complete.

In some embodiments the Exchange may publish all available orders, or itmay publish a subset of such orders, or it may not publish availableorders. It may also use any kind of matching rules and order lifecyclerules including conditional order cancellations, as is practised onsecurities exchanges elsewhere.

FIG. 12 illustrates the exchange process for exchange of tokens ofdifferent currencies, according to an example embodiment of the presentinvention. A user 1's device 1210 has a token (or multiple tokens inclass A) but user 1 wants tokens in class B. Device 1210 makes a requestto Exchange 1230 to exchange the class A token for the class B token.User 2's device 1220 has a token (or multiple tokens), in class B, butuser 2 wants tokens in class A. Device 1220 makes a request to Exchange1230 to exchange the class B token for the class A token.

The Exchange 1230 receives the Value Tokens to be swapped from therespective user devices and requests to exchange the Value Tokens.Responsive to receiving the exchange request and the Value Tokens,Exchange 1230 makes an escrow request for the class A token to the Mintassociated with that token 1240, and receives an escrow confirmation.The Exchange makes an escrow request for the class B token to the Mint1250 associated with that token, and receives an escrow confirmation.Responsive to receipt of both escrow confirmations, the exchange thenmakes swap requests for both tokens at their respective mints. Uponreceipt of the newly issued Value Tokens, the newly issued class B tokenis sent to user 1's device 1210, and the new class A token is sent touser 2's device 1220.

While an escrow is in place, attempts to swap the Value Token fromentities other than the Exchange may be rejected. For example, this maybe accomplished, by updating a data repository including token validityand/or double spend data to indicate the status of the Value Token is“in escrow”. Mints may be configured, e.g., as part of the Value Tokenswap validation process to reject requests to swap such tokens.

If one of the attempts to escrow the Value Tokens by the Exchange fails,e.g., because the relevant Mint refuses the request, the Exchange maycause the status of the other token, which had been placed in escrowstatus, to be released, e.g., by sending an appropriate message to theMint for that token.

The process of match-making between A and B may be accomplished by avariety of methods. The process described in this subsection assumes theparties wanting to make the exchange have already been identified to thesystem and to each other. Also, more complicated exchange patterns withmultiple parties seeking exchanges, and/or exchanges of multiple tokensat the same time, or other more complicated exchanges, may also bedeveloped using variants based on the basic protocol described here.

FIG. 13 illustrates the same process showing the actions of each user ina separate flow, as well as the respective message exchanges. Also,optionally, added to the end of the exchange procedure, User 1210 mayrequest a swap of the newly received class B token, and user 1220 mayrequest a swap of the newly received class A token, e.g., to exchangecoded for intrinsic Value Tokens for user in a further purchase.

It will be appreciated that procedures similar to the Exchange processmay be used in other contexts where pre-clearing transactions isdesirable. For example, mints conducting swaps for particularly large orother high risk tokens may use similar approaches to pre-clear atransaction prior to making a swap.

Example: Value Token Swap with Network of Mints

In this example, each issuer issues a respective class of Value Tokenusing one or more Mints; each Mint may include one or more redemptionand/or signing functions. In some cases, a particular Mint may bothissue and redeem Value Tokens of a particular Class; in other casesthese operations may reside at separate Mints. The Mints may beconfigured to operationally provide either redemption, signing or bothcapabilities, so that a single Mint may act as a redeemer and a signer.A Mint that provides redemption or signing can be deployed andconfigured to use one or more servers that share a common set ofrepositories that store Value Token related information, for exampledatabases. This information may be distributed across multiple databasesbased, e.g., on the index used. Example indices might include a portion,e.g., the first byte of a token hash, denomination index, transactionid, etc. It will be appreciated that differing arrangements of Mints mayoffer varying operational capabilities and outcomes.

In the present example, each Coded Value Token has associated with it aClass, Value, at least one Issuing Mint ID and at least one RedemptionMint ID. The Issuing Mint ID is the identity of the Mint that issued theCoded Value Token and the Redemption Mint ID identifies the Mint thatcan verify the Coded Value Token. Mint identities may be certified by anappropriate authority, for example a Certificate Authority. For anIntrinsic Value Token the Issuing Mint and the Redemption Mint aretypically the same and the Mint ID is implicitly determined by a key setused to sign the Intrinsic Value Token. When a Mint verifies a set ofIntrinsic Value Tokens and provides a set of Coded Value Tokens as aswap, the verifying Mint assigns a Redemption Mint ID to the Coded ValueToken. The Coded Value Token is signed with the specific Coded ValueToken-signing key of the issuing Mint. For example, if Mint A issues anIntrinsic Value Token set and then at a subsequent time redeems a tokenfrom that Intrinsic Value Token set, Mint A may also issue Coded ValueToken(s) for redemption at another Mint, for example Mint C. When Mint Creceives such Coded Value Token, e.g., as part of a swap request, Mint Cmay, after verification, redeem these Coded Value Token(s) for IntrinsicValue Token(s).

FIG. 14 illustrates an example method for verifying a set of Coded ValueTokens by a Mint, according to an example embodiment of the presentinvention. When a Mint verifies a set of Coded Value Token(s) (forexample, that all share the same Redemption Mint ID), the Mint:

-   -   reads the Issuing Mint ID from the request (for example, from        information associated with a Coded Value Token) message    -   retrieves the public Coded Value Token-key for that Issuing Mint        (for example, either from the request message, or a local cache,        or from the other Mint)    -   verifies the Coded Value Token set are properly signed with that        public key    -   verifies that the combination of Issuing Mint ID, Coded Value        Token number (for example a serial number that represents a        unique identifier (UID) that is unique to the signing mint does        not previously occur in its Coded Value Token data repository    -   signs the requested Intrinsic Value Token or Coded Value Token        with its corresponding Issuing Mint active signing keys.

Example: Secure Token Escrow in a Network of Mints Issuing DifferenceClasses of Value Tokens

In this example, a Mint's data repository may include information setscorresponding to Value Tokens. Part of this information set may includetoken state information, such as double spending information to preventmultiple redemptions of the same token. As part of this information, onepossible value of token state information for a Value Token may be ‘InEscrow’. For example, the ‘In Escrow’ state may indicate that theassociated Value Token is part of a multi-phase transaction. Forexample, such a multi-phase transaction may involve multiple Mints ofthe same Class and/or multiple Mints of different Classes. In somecases, a payee or swap recipient, does not even have to be assignedwhile a set of value tokens state information is marked as ‘In Escrow’.They could be marked “In Escrow” as a precursor to a transaction.

The set of operations involving a token set with state “In Escrow” maybe indivisible and irreducible, such that all of the operationsinvolving such a token set occur or no operations involving such a setoccur. For example, in this manner, if there are a number ofparticipants involved in an overall transaction, where such atransaction may involve multiple constituent transactions and/oroperations involving one or more token sets where at least one of whichhas a state of “In Escrow”, these operations and their constituents, maybe arranged so that a controlling logic, specification and/or operatingprogram may require that each of these constituent steps is undertaken,for example in a specified sequence or other organization of suchprocesses, before the state of the token set is changed from “In Escrow”state to another state.

A complex swap is a Value Token swap where a set of value tokens frommultiple Mints (for example of the same Class or multiple Classes) areswapped for another set of value tokens. An Exchange device may beprovided to controls the secure exchange of value tokens of differentclasses in a complex swap.

An Escrow management unit may be associated with a Mint. For example theescrow management unit may be cryptographically bound to the Mint, andmay manage issuing of a Coded Value Token set until the Escrowconditions for the exchange, are met, or the exchange transaction iscancelled.

A Secure Transaction Controller (STC) may be provided to control theatomicity of Complex Swaps. FIG. 16 illustrates an example securetransaction controller D10, according to an example embodiment of thepresent invention. The escrow management system (or just the STC) can beimplemented, in whole or as part of a hardware device, or as a softwarecontrolled device running on a secure processor. The STC may ensure thateither all the constituent parts are executed (rolled forward) or noneof them are (all parts are cancelled). For example, an STC may be partof an Escrow management system. Escrow transactions may have theirrespective payee associated when requested, or alternatively at asubsequent time, such as when the transaction is rolled forward, andpayee is assigned by STC. Conversely if the transaction is rolledbackward, then the transaction is marked as cancelled. In the case onlythe original payer may receive the Coded Value Token once they areidentified. For example, if a Complex Swap is cancelled, the relevantMint may allow participants to swap the values tokens originallysubmitted in the Complex Swap for fresh tokens.

The STC D10 includes a processor D12 in communication with memory D14.The escrow controller may include an exchange request module D40, anexchange matching module D50, and an exchange execution module D60,which are stored in memory D14. Memory D14 may include request and/orresponse interfaces D20, client message hander(s) D22, and acommunication management module D24. The STC may also include mintmessage hander(s) D26 and Mint interaction interface(s) D28. The escrowcontroller is in communication with various Mints and may receiveindications that sets of Value Tokens should be placed in escrow.

This combination of elements may incorporate creation and management ofone or more audit trails and may use D30 key management capabilities forsecuring such audit trails.

D30 A key management unit D30 may be provided to handle encryptions anddecryptions of keys, provide public key encryption, and the like, e.g.,as described in the various process diagrams described herein that usekey systems. D30 may be used by other STC elements for securingcommunications and/or supporting authorization and/or authenticationcapabilities.

An exchange request module D40 may be provided to receive and processrequests for exchange transactions received from clients.

An exchange matching module D50 may be provided to match client requestsfor exchanges, or to receive such matchings from some other system thatidentifies such potential matches. The exchange matching module mayprovide various sorts of exchanges, such as exchanges that have beenidentified elsewhere, market orders, auction, and the like, describedelsewhere in this disclosure, and may further include using rulesmanaged in Rule management module D34.

An exchange execution module D60 may execute an exchange after anacceptable match has been identified by the Exchange matching module.

Each of D40, D50 and D60 may in combination with D36 create and maintainone or more audit trails and/or other records pertaining to theoperations of such entities.

D34 Rules management may manage rules sets for one or morerequest/response, client and/or Mint operations. D34 may facilitate thecreation and deployment of one or more rule sets in response torequests/response and/or Mint interactions where such rule sets areapplied to such interactions dynamically. Rule sets may, in someembodiments, have further rule sets that determine the type ofoperations such sets are associated with and may pass such informationsets to other STC elements, for example D60 for instantiation.

Secure processing for all the other modules may be facilitated by secureprocessing module D32. From the time a request is made until executionof an exchange is completed, the escrow status of tokens may be handledby Escrow storage management unit D36. Such status may be secured thoughusing D30 in combination with D32, such that STC processing of exchangerequests and responses, including interactions with Mints is end-to-endsecure. In some embodiments, D32 may be instantiated as a hardwaresystem, for example as a System on a Chip (SOC), such as for example anARM SOC, whereby the secure processing in undertaken with that SOCsecure processing domain. In some embodiments, an STC may beinstantiated as a hardware device, incorporating such SOC, whereby theprocessor D12, Memory D14 and all other system elements are embodied insecure hardware, which may be further hardened. It will be appreciatedthat all of the above described modules could also be provided asspecial purposes hardware, ASICs or FPGAS, or the like.

FIG. 17 illustrates an example process flow for a Value Token exchange,using a secure transaction controller E14, according to an exampleembodiment of the present invention. For illustration, the complex swapmay involve clients E10 and E12, secure transaction controller E14, andMint E16 for Value tokens of Class X and Mint E18 for Value Tokens ofClass Y.

In E20, Client E10 may request an exchange of a set of Value tokens ofClass X for Value Tokens of Class Y. In response, the secure transactioncontroller may send an escrow request for the Mint E16 responsible forredeeming class X tokens. In E24, the secure transaction controller mayreceive an acknowledgement indicating that the set of class X tokens hasbeen placed in escrow which may be in the form of or include an escrowtoken A. In E26, in response to receiving the acknowledgement, the STCmay also inform Client E10 that the tokens have been placed in escrow,and may provide the Client E10 with the escrow token A.

At the same or at some later time, in E30, Client E12 may send a requestto exchange tokens of class Y for tokens of class X. In E32 the STC maymake an escrow request to Mint E18 that handles redemptions of ValueTokens of Class Y. In E32, the STC may receive an acknowledgement fromMint E18 indicating the set of tokens of Class Y has been placed inescrow, which may in in the form of or include an escrow Token B. InE36, the STC may also inform Client E12 that the tokens have been placedin escrow and may provide the escrow token B to client E12.

In E40, the requests from Clients E10 and E12 can be matched, either bythe STC, or by some other system that identifies the matching andcommunicates the match to STC. In response to the STC determining thatthere is match, the STC communicates with Mints to complete theexchange. The communications with the multiple mints may be doneatomically. In E50, the STC communicates with the Mint E16 to finalizethe request for swapped tokens for the set of tokens of Class X, byprovided a finalization request including the escrow token A, and arequest for new tokens of Class X which will be provided to client B. InE52 the STC communicates with mint E18 to finalize the request forswapped tokens for the set of tokens of Class Y, by sending the escrowtoken B, and request to execute a swap for new tokens of class Y forclient A. In E54, coded Value Tokens of class X may be received fromMint E16 by the STC. These tokens may be coded to indicate Client E12 isthe intended recipient. In E56 coded value tokens of Class Y may bereceived from Mint E18 by the STC. These tokens may be coded to indicateclient E10 is the intended recipient. In E60, the STC sends the codedValue Tokens of Class X to client E12. In E62, the STC sends the codedValue Tokens of Class X to client E10. The clients may subsequently swaptheir respective coded Value Tokens for intrinsic Value tokens at theappropriate Mint.

It will be appreciated that the STC performs E50, E52, E54, E56, E60,and E62 in an atomic fashion, so that all the actions are completed.

FIG. 15 illustrates an example complex transaction using a complextransaction id and multiple Mints, according to an example embodiment ofthe present invention. In some embodiments, when initiating a ComplexSwap, an STC creates a unique identifier for the transaction(illustrated as “m”). In some embodiments, an STC, which is controllingthe transaction, creates and manages records of such transaction,whereby such record is controlled, and where appropriate, secured by,such STC. In some embodiments, such records may be stored locally (forexample in STC accessible memory or storage medium) and/or in adistributed manner (for example in cloud storage).

When receiving Value Tokens from a user, the STC sends an Escrow requestto the Mint that includes the Complex Swap transaction id as well as anexpiry date/time. The Mint verifies the tokens (and puts them on thedouble-spent list) and returns an Escrow Token.

The STC does this with every Mint that is part of the Complex Swap. Forexample as Intrinsic Value Token and Coded Value Token are presented toan STC, such STC may contact those set of Mints associated with suchIntrinsic Value Token and Coded Value Token, and as such may maintain anetwork of Mints sufficient for the effective evaluation and managementof the transaction involving such tokens.

When all Escrow tokens have been received and verified by theappropriate Mints, the STC records the decision to execute and requestsfinalization of the Escrow transaction to each one of the cooperatingMints. These Mints in turn return the final Coded Value Tokens for theswaps that are subsequently distributed by the STC to the participantsinvolved in the transaction.

When the STC decides to cancel the transaction (for example, because notall preconditions could be met in the required time period), the STCrecords the cancellation in its repository and requests cancellationsfrom each of the cooperating Mints.

The Escrow Request and Escrow Token may also include an expiry date/timeafter which the Escrowed tokens can be cancelled. In some embodiments,an Escrow token may also identify or be directly associated with theinitial presentation to an STC, for example a deposit, and consequentlysuch token is only valid for that transaction.

In each case there will be a unique piece of data (illustrated as ‘g’)that is stored by each Mint involved in the Complex Swap. When the STCdecides to finalize the transaction the Escrow finalization messageincludes a piece of data, such as a private key, (illustrated as ‘s_e’)that can be verified using g. Alternatively, when the STC decides tocancel the transaction the request message includes a piece of data(illustrated as ‘s_c’) that can also be verified using g. In someembodiments there will be a controlling secret ‘r’ from which ‘g’, ‘s_e’and ‘s_c’ are derived.

FIG. 18 illustrates an alternative example process flow for a ValueToken exchange, using a secure transaction controller, that includes acomplex swap transaction key according to an example embodiment of thepresent invention. For illustration, the complex swap may involveclients F10 and F12, secure transaction controller F14, and Mint F16 forValue tokens of Class X and Mint F18 for Value Tokens of Class Y.

In F20, Client F10 may request an exchange of a set of Value tokens ofClass X for Value Tokens of Class Y. In response, the secure transactioncontroller may send an escrow request for the Mint F16 responsible forredeeming class X tokens. In F24, the secure transaction controller mayreceive an acknowledgement indicating that the set of class X tokens hasbeen placed in escrow, which may be in the form of or include an escrowtoken A. In response to receiving the acknowledgement, the STC may alsoinform Client F10 that the tokens have been placed in escrow and mayprovide the escrow token A to the client.

At the same or at some later time, in F30, Client F12 may send a requestto exchange tokens of class Y for tokens of class X. In F32 the STC maymake an escrow request to Mint F18 that handles redemptions of ValueTokens of Class Y. In F34, the STC may receive an acknowledgement fromMint F18 indicating the set of tokens of Class Y has been placed inescrow, which may in the form of or include an escrow token B. In F36,the STC may provide an indication to Client F12 that the set of tokensof Class Y has been placed in escrow and may provide the escrow token Bto client B.

In F40, the requests from Clients F10 and F12 can be matched, either bythe STC, or by some other system that identifies the matching andcommunicates the match to STC. In response to the STC determining thatthere is match, in F50 the STC communications with send a finalizationmessage to client A included escrow token B and private key s_e. In F52,the STC communicates a finalization message to client F12 includingescrow token A and private key S_e.

In F54, in response to receiving the finalization message from the STC,the client B may request to swap of the escrow token A for intrinsicvalue tokens of class X at Mint F16. IN F56, which may happenasynchronously with F54, in response to receiving the finalizationmessage from the STC, the client A may request a swap of the escrowtoken B for intrinsic value tokens of class Y from Mint F18. In F58,client B may receive the requested intrinsic value tokens. In F60,client A may receive the requested intrinsic value tokens of class Y.

Example: Key Handling

An STC may create a unique key for a Complex Swap, which may be publickey (g) of which is sent with each Escrow request. The public key may bestored by each Mint in manner that associates it with the escrowedtokens. The Escrow Token may also contains this public key or a one-wayhash thereof.

In some embodiments, when an STC executes a Complex Swap, it signs anEscrow finalization message with the private key (‘s_e’) and returns toeach of the user's clients such an Escrow finalization message informingthe user that the pre-settled transaction has been successfullyundertaken.

In this example, each user can now contact the relevant Mints andretrieve the appropriate Coded Value Token for the token swap using theEscrow Token and Escrow Finalization message.

Alternatively, to cancel the transaction, the STC signs a requestmessage (‘s_c’) that can be used by user's clients to prove to a Mintthat the transaction has been cancelled by the STC.

In some embodiments, a private key can comprise two random secrets suchthat the public key is a hash of the image of each secret after aone-way function (for example such as a Merkle function). The STC cannow reveal either the first secret and the second one-way (for example,to execute) or the second secret and the first one-way (for example, tocancel).

In this example, the combination of r_e and r_c form the controllingsecret ‘r’. The following diagram illustrates the process by which theSTC derives the public key ‘g’ from two random secrets ‘r_e’ and ‘r_c’using two one-way functions f1 and f2.

FIG. 19 illustrates an example procedure for deriving the public key,according to an example embodiment of the present invention. The publickey ‘g’ is provided to the mints as described in section. When the STCexecutes a Complex Swap it provides the message ‘s_e’ to the clientwhich includes r_e and fl(r_y). The mint subsequently verifies theresult of applying the one-way functions with the stored public key ‘g’.FIG. 20 illustrates an example procedure for verifying an executemessage, according to an example embodiment of the present invention.

Alternatively, if the STC decides to cancel a Complex Swap it providesthe message ‘s_c’ to the client which includes r_c and fl(r_e). The mintsubsequently verifies the result of applying the one-way functions withthe stored public key ‘g’. FIG. 21 illustrates an example procedure forverifying a cancel message, according to an example embodiment of thepresent invention.

Further Example: Escrow Finalization Messages

In some embodiments, in place of an assigned payee identity beingincluded in a Coded Value Token, an Escrow Finalization message can be atoken swap of token requests for final tokens.

The STC can store the original token requests for Intrinsic Value Tokenthat should be returned as part of the swap. When the escrow isfinalized, the STC relays the token requests to the appropriate Mint(s)and returns the result to the user's client. In this manner, retrievingthe Coded Value Token and swapping the Coded Value Token for IntrinsicValue Token may be bypassed.

STC Exchange Operations

An STC may receive a set of Value Tokens with sets with a value tokenrequests including an expressed enumerated value in the class of desiredTokens. For example, a price can be a set in one or more Value Tokenrequests (either same Class or different Classes). The message indicatesa willingness to sell the Value Tokens in return for Value tokensrequested.

-   -   The exchange STC escrows the tokens and creates a Complex Swap        transaction. This transaction is effectively the ‘order’ and        will remain valid until fulfilled or cancelled.    -   If a match is made with another complimentary order, the        exchange STC finalizes the transaction and returns the Coded        Value Token to the parties involved.

These orders may or may not be published. Publication may be to anyselected and/or authorized location (for example, web, network, cloudetc.), repository, client and/or the like.

In some embodiments, a ‘Market order’ may just include a set of ValueTokens and a requested token class (for example, without a price). TheExchange can then match with the best price currently available for therequested class.

An STC may also include or have access to one or more rule setsdetermining the operation of such an STC. Each STC may be able toexecute such rule sets to control exchanges. Examples of such rulesetsare illustrated below:

Store and Forward Service

For example, in an embodiment of a store and forward service, thefollowing rule sets may be operated:

-   -   A Store-and-Forward device receives a request to send a set of        Value Tokens to a particular recipient.    -   The recipient may not be a member of the system, or may not be        ready to accept payments, or we may want to notify a recipient        in real-time of the availability of a payment without revealing        the contact details of that recipient.    -   The Store-and-Forward device's STC requests escrow for the Value        Tokens to ensure the tokens are real and that the service is not        used to spam unsuspecting users with fake payments.    -   The Store-and-Forward device sends a notification to the        recipient that a payment is available    -   When the recipient requests to collect the payment, the Escrow        is finalized and the Coded Value Token returned to the recipient    -   The sender may (or may not) receive a notification when the        payment has been collected.    -   The payment may be cancelled by the sender as long as it has not        been collected yet.

Multi-Currency Payment (e.g., Using Loyalty Points Program)

An example embodiment of a Merchant STC where:

-   -   The Merchant requests tokens for more than one class at the same        time from the users wallet.    -   The user sends sets of Value Tokens for each of these classes in        a single message.    -   The Merchant's STC creates a Complex Swap and sends Escrow        requests for each of these sets of Value Tokens to their        corresponding Mints.    -   After all Escrow Tokens have been received, the Merchant's STC        finalizes the Escrow.

Auction

An example embodiment of an STC where:

-   -   The Auction device stores a reference to the highest bidder for        a particular item.    -   When a set of Value Tokens is received that have more value than        the current highest bidder, they are Escrowed by the Auction's        STC. If the Escrow Token is received, the previous highest        bidder's Escrow is cancelled.    -   When the time limit of the Auction has passed, the Escrow is        finalized with the seller as recipient.

Crowd-Funding

An example embodiment of an STC where:

-   -   A party requests a certain amount of Value tokens in a        particular class.    -   Each set of Value Tokens received is escrowed by the STC.    -   When the total requested amount has been reached, the STC        finalizes the Escrow with the payee id of the party.

Combinations

In some embodiments, multiple Escrow tokens can be finalized at the sametime (at the same Mint) and can be combined into a single Coded ValueToken.

Examples: Using Exchanges for Payment Processing

In some example embodiments, exchanging a set of Intrinsic Value Tokenfor a set of Coded Value Token can be an atomic operation where inputtokens are stored in the spent token repository at the same time as asigned Coded Value Token is associated with them.

This results in a consistent operational behavior, such that(Re-)Sending a request with the same set of Intrinsic Value Tokenproduces the same set of Coded Value Token.

In some embodiments, exchanging a (set of) Coded Value Token for a (setof) Intrinsic Value Token can be an atomic operation where the signedIntrinsic Value Token are associated with the input Coded Value Token.

This results in a consistent operational behavior, such that(Re-)Sending a request with for a Coded Value Token requires the sameset of Intrinsic Value Token requests and produces the same IntrinsicValue Tokens.

FIG. 22 illustrates a flowchart of an example process for processing anexchange of Intrinsic Value Token for a Coded Value Token. This processmay be carried out by a Mint, e.g., as a Mint deposit process. It willbe appreciated that, alternatively, in place of a Coded Value Token, ifthere is an escrowed exchanged, an escrow token may be sent in place ofa Coded Value Token.

FIG. 23 illustrates a flowchart for an example process for a Coded ValueToken (or an escrow token) for freshly signed Intrinsic Value Token.This process may be carried out by a Mint, e.g., as a Mint withdrawalprocess.

Payment Examples

It will be appreciated that exchanges, as described in the precedingsections, can be used to facilitate payment transaction of various typesbetween client devices or users. The following examples illustratevarious scenarios that may arise with such exchanges.

Example Normal Payment Exchange

FIG. 24 illustrates a normal exchange in an example exchange processused for payments, according to an example embodiment of the presentinvention. In the normal exchange, a User B may receive value tokensfrom User A as a form of payment. User B checks the value tokens with aMint and receives its own value tokens in return.

-   -   1. User A sends its Payment Message with encrypted Intrinsic        Value Token to User B    -   2. User B exchanges the Payment Message for a Coded Value Token    -   3. Mint checks the Intrinsic Value Token were not already spent        and issues a Coded Value Token to User B    -   4. User B returns the Coded Value Token to User A as a        confirmation of the payment    -   5. User B exchanges the Coded Value Token for new Intrinsic        Value Token2    -   6. Mint checks the Coded Value Token was not already spent and        issues Intrinsic Value Token2

Example Retry Exchange

In some embodiments, when a request from User B to a Mint fails (for anyreason except a permanent failure, for example a network error), User Bsimply resends the request. FIG. 25 illustrates a retry exchange in anexample exchange process used for payments, according to an exampleembodiment of the present invention.

-   -   1. User A sends a payment message with encrypted Intrinsic Value        Token to User B    -   2. User B requests exchange of the Payment Message for a Coded        Value Token    -   3. Mint checks the Intrinsic Value Token were not already spent        and issues a Coded Value Token to User B    -   4. User B never receives response (timeout or temp failure)    -   5. User B resends exact same request    -   6. Mint determines tokens have already been spent in another        transaction and returns Coded Value Token for that transaction        (as it was also issued to User B)    -   7. User B returns the Coded Value Token to User A as a        confirmation of the payment

User B then proceeds to exchange the Coded Value Token for its ownIntrinsic Value Token in the normal way.

Example Payment Resending

In some embodiments, for example User A resends the same value tokensafter a previous payment has been completed. User B may or may notaccept the resending of the payment.

For example, if User B delivers a digital message in response to apayment, the exact same digital message is delivered. FIG. 26illustrates resending in an exchange process used for payments,according to an example embodiment of the present invention.

-   -   1. User A sends a Payment Message with encrypted Intrinsic Value        Token1 to User B    -   2. User B exchanges the Payment Message for a Coded Value Token1    -   3. Mint checks the Intrinsic Value Token were not already spent        and issues a Coded Value Token1 to User B    -   4. User B returns the Coded Value Token to User A as a        confirmation of the payment. (The process of exchanging Coded        Value Token1 for Intrinsic Value Token2 is described in more        detail elsewhere in this disclosure)    -   5. User A resends the Payment Message, or sends a new Payment        Message with the same Intrinsic Value Token1.    -   6. User B attempts an exchange with a new transaction id and the        Payment Message received.    -   7. Mint determines tokens have already been spent in another        transaction and returns Coded Value Token for that transaction        (as it was also issued to User B).    -   8. User B detects that Coded Value Token is actually for t1 (not        t2) and returns either a failure or the original digital        delivery.

Example Payment Cancellation

In some embodiments, User A sends a payment to User B but cancels thepayment before User B can exchange the tokens. FIG. 27 illustratescancellation of a payment, in an exchange process used for payments,according to an example embodiment of the present invention.

-   -   1. User A sends a Payment Message with encrypted Intrinsic Value        Token1 to User B    -   2. User A requests exchange of Intrinsic Value Token1 for Coded        Value Token (possibly with blinding factors to prove ownership        of the Intrinsic Value Token1)    -   3. Mint determines that Intrinsic Value Token1 were not already        spent and issues a Coded Value Token1 for User A    -   4. (User A exchanges Coded Value Token1 for Intrinsic Value        Token2, however this is not significant for this example)    -   5. User B attempts to exchange the Payment Message with        encrypted Intrinsic Value Token1 for a Coded Value Token    -   6. Mint determines that Intrinsic Value Token1 are already spent        but that the associated Coded Value Token is not for User B and        returns a permanent failure

Example Retry Exchange: Coded for Intrinsic

In some embodiments, exchanging Coded Value Token for Intrinsic ValueToken can be retried as long as the second Intrinsic Value Token requestmessage matches the first Intrinsic Value Token request exactly. (i.e.exact same unsigned blinded Intrinsic Value Token). FIG. 28 illustratesan example retry exchange of coded value tokens for intrinsic tokens, aspart of a payment process, according to an example embodiment of thepresent invention.

-   -   1. User B requests exchange of Coded Value Token1 for its own        Intrinsic Value Token2    -   2. Mint checks the Coded Value Token1 was not already spent and        issues (and stores) Intrinsic Value Token2    -   3. User B does not receive response from Mint (timeout or        failure)    -   4. User B resends request for exchange of Coded Value Token1 for        its own Intrinsic Value Token2    -   5. Mint determines that Coded Value Token1 was already spent and        verifies Intrinsic Value Token2 request against the Intrinsic        Value Token2 stored and responds with Intrinsic Value Token2    -   6. User B receives Intrinsic Value Token2

Example: Payment of Partially Spent Tokens

FIG. 29 illustrates an example attempt to exchange a set of tokens whichare partially spend, according to an example embodiment of the presentinvention.

In some embodiments, when a User sends a Payment Message that containstokens some of which are spent and others are not, the Mint creates aCoded Value Token for the unspent tokens allowing them to be cancelledonly (for example, cancel “In Escrow” state). The User sending thetokens for exchange receives a permanent failure.

In the following example, the UIntrinsic Value Token is the set ofunspent Intrinsic Value Token and the SIntrinsic Value Token is the setof already spent Intrinsic Value Token.

-   -   1. User A requests exchange of previously spent tokens and        unspent tokens.    -   2. Mint finalizes any cancelled tokens, spends any unspent        tokens and issues a Coded Value Token2 for their combined value.    -   3. Mint responds with all Coded Value Token1 for transactions in        which tokens were previously spent as well as the Coded Value        Token2    -   4. User A checks its transaction record for the Coded Value        Token1 and retries the exchange of any Coded Value Tokenx that        have not been exchanged for Intrinsic Value Token yet, yielding        Intrinsic Value Token3.

Example: Idempotent Responses to Resends

In some embodiments described in the present disclosure, at variouspoints in an interaction, communications may fail and cause (eitherautomatic or explicit) resend or retries of a request. These failuresmay occur at different points, e.g.:

-   -   1. Communications failure during request sending    -   2. Communications timeout while waiting for response    -   3. Temporary processing failure (unavailability of resources—for        example, network errors, repository unavailable, internal server        configuration and/or the like)    -   4. Permanent processing failure (request syntax error, or        request denied)    -   5. Communications failure during response sending    -   6. Also, termination of the client application while a request        is being processed may occur.

These situations may be conveniently addressed by configuring a clientto always retry a request with the outcome that it will yield the sameresult.

For example, a transaction may have state, such that a client firstrecords a transaction (where such transaction may, in some embodiments,be prospective) and can always resend such a transaction using valuesstored with the transaction record managed by such client. Whenever aresponse is received, the local client transaction record is updated andas such the transaction state is updated. The state update may cause anext request to be sent.

In some embodiments, a client retains transaction state as may thecounter party of such a transaction, for example a Mint, STC, anotherclient, server or other entity acting as a counter party.

Example: Final (Indelible) Transaction

In some embodiments, as a token transaction always results in a tokenswap, a write once ledger may provide an indelible audit trail for suchtransactions. For example, the state of the system may be modified byappending transactions to a ledger so as to create an indelible recordfor those transactions. This record may be written to write-once mediato preserve the state of the system and the transaction history across asystem failure. For example, this may employ one or more cryptographictechniques to establish the veracity and irrefutable unique state ofsuch a record. For example, a blockchain, Merkel Tree and/or other hasharrangements or digital signatures may be used. For example, once atoken has been decrypted by redeeming Mint, e.g., by its intrinsic tokenverification unit, the token is added to at least one appropriate andaccessible spent token list. Even when the transaction fails becausesome tokens have already been spent at the time of the request, theparticular failure is caused by that combination of tokens and unspenttokens and the transaction should be recorded and the unspent tokenswill be marked as spent (or actually cancelled).

It will be appreciated that all of the disclosed methods and proceduresdescribed herein can be implemented using one or more computer programsor components. These components may be provided as a series of computerinstructions on any conventional computer readable medium or machinereadable medium, including volatile or non-volatile memory, such as RAM,ROM, flash memory, magnetic or optical disks, optical memory, or otherstorage media. The instructions may be provided as software or firmware,and/or may be implemented in whole or in part in hardware componentssuch as ASICs, FPGAs, DSPs or any other similar devices. Theinstructions may be configured to be executed by one or more processors,which when executing the series of computer instructions, performs orfacilitates the performance of all or part of the disclosed methods andprocedures.

It should be understood that various changes and modifications to theexample embodiments described herein will be apparent to those skilledin the art. Such changes and modifications can be made without departingfrom the spirit and scope of the present subject matter and withoutdiminishing its intended advantages. It is therefore intended that suchchanges and modifications be covered by the appended claims. Also, itshould be appreciated that the features of the dependent claims may beembodied in the systems, methods, and apparatus of each of theindependent claims.

1-74. (canceled)
 75. A system for issuing cryptographically signeddigital tokens of a first class as part of an exchange of digital tokensof different classes, comprising: a processor; a memory in communicationwith the processor; a secure memory storing a mint key; instructionsstored in the memory and executed by the processor, to (a) responsive toa first client device requesting from an exchange server an exchange ofa first set of cryptographically signed digital tokens of the firstclass for a second set of digital tokens of a second class, receive amessage from the exchange server including the first set of digitaltokens, confirm the validity of the first set of digital tokens, causethe first set of digital tokens to be placed in an escrow state, send anacknowledgement message to the exchange server indicating the first setof digital tokens are valid and have been placed in an escrow state, (b)subsequent to sending the acknowledgement message, receive aninstruction from the exchange server to swap the first set digitaltokens for a new set of coded digital tokens of the first class andsecond client device information, (c) responsive to receiving theinstruction, cryptographically sign, using the mint key, each of the newset of coded digital tokens, each of the new set of coded digital tokensincluding information sufficient to confirm the second client device isthe original recipient of that token, and (d) send the new set of signedcoded digital tokens to the second client device.
 76. The system ofclaim 75, wherein each of the new set of coded digital tokens is encodedwith information with sufficient information to identify the secondclient device.
 77. The system of claim 75, wherein each of the new setof coded digital tokens is not encoded with sufficient information todetermine the identity of the second client device but does containsufficient information to confirm the second client device is theoriginal recipient of that token when that token is presented for use bythe second client device.
 78. The system of claim 75, wherein theinstructions executed by the processor are further configured to receiveinformation from an escrow finalization message sent to the secondclient device by the exchange server, and responsive to receiving theinformation from the escrow finalization message, to permit the secondclient device to retrieve the new set of coded digital tokens from thesystem.
 79. The system of claim 75, wherein the instruction receivedfrom the exchange server further includes a complex exchange transactionidentifier.
 80. The system of claim 75, further comprising: a spenttoken repository, wherein confirming the validity of each of the firstset of digital tokens including checking the spent token repository forinformation regarding that token.
 81. The system of claim 75, furthercomprising: a valid token repository, wherein confirming the validity ofeach of the first set of digital tokens including checking the validtoken repository for information regarding that token.
 82. The system ofclaim 75, further comprising: an escrow unit, the escrow unit configuredto place each of the first set of digital tokens in an escrow state. 83.The system of claim 75, further comprising: a spent token repository,wherein the escrow unit is configured to place each token in the firstset of digital tokens in an escrow state by adding a temporary escrowcoded entry corresponding to the that token to the spent tokenrepository.
 84. The system of claim 83, wherein the instructions arefurther configured to cause the temporary escrow coded entries for eachof the first set of digital tokens to be changed to a spent token entrybefore the new set of digital tokens is sent.
 85. The system of claim75, wherein determining the first set of digital tokens is validincludes determining the first client device is the original recipientof each of the first set of digital tokens.
 86. A method of issuing newcryptographically signed digital tokens as part of providing a securetoken exchange transaction for cryptographically signed digital tokensof different classes, comprising: responsive to an exchange serverreceiving a first digital message including a first request from a firstclient device to exchange a first set of digital tokens of a first classfor digital tokens of a second class, receiving a message including thefirst set of digital tokens from the exchange server; after receivingthe message, confirming the validity of each of the first set of digitaltokens; after receiving the message, placing each of the first set ofdigital tokens in an escrow state; sending an acknowledgement confirmingthat all of the digital tokens in the first set of digital tokens arevalid and have been placed in escrow; subsequent to sending theacknowledgement, receiving an instruction from the exchange server toswap the first set digital tokens for a new set of coded digital tokensof the first class and second client device information; responsive toreceiving the instruction, cryptographically signing using a mint keyeach of the new set of coded digital tokens, each of the new codedtokens including information sufficient to confirm the second clientdevice is the original recipient of that token; and sending the new setof signed coded digital tokens to the second client device.
 87. Themethod of claim 86, wherein each of the new set of coded digital tokensare encoded with information which can be used to indicate the identityof the second client device.
 88. The method of claim 86, wherein theeach of the new set of coded digital tokens are not encoded withsufficient information to indicate the identity of the second clientdevice but do contain sufficient information to confirm the secondclient device is the original recipient that token when that token ispresented for use by the second client device.
 89. The method of claim86, further comprising: receive information from an escrow finalizationmessage sent to the second client device by the exchange server, andresponsive to receiving the information from the escrow finalizationmessage, permitting the second client device to retrieve the new set ofcoded digital tokens.
 90. The method of claim 86, wherein determiningthe first set of digital tokens is valid includes determining the firstclient device is the original recipient of each of the first set ofdigital tokens.
 91. The system of claim 86, further comprising: whereinconfirming the validity of each of the first set of digital tokensincluding checking a valid token repository for information regardingthat token.
 92. The system of claim 86, further comprising: placing eachtoken in the first set of digital tokens in an escrow state by adding atemporary escrow coded entry corresponding to that token to a spenttoken repository.
 93. The method of claim 92, further comprising:changing the temporary escrow coded entries for each of the first set ofdigital tokens to a spent token entry before the new set of digitaltokens is sent.
 94. A non-transitory machine readable medium storing aprogram, configured to, when executed by a processor, to cause aprocessor to responsive to an exchange server receiving a first digitalmessage including a first request from a first client device to exchangea first set of digital tokens of a first class for digital tokens of asecond class, receive a message including the first set of digitaltokens from the exchange server; after receiving the message, confirmthe validity of each of the first set of digital tokens; after receivingthe message, place each of the first set of digital tokens in an escrowstate; send an acknowledgement confirming that the first set of digitaltokens is valid and has been placed in escrow; subsequent to sending theacknowledgement, receive an instruction from the exchange server to swapthe first set digital tokens for a new set of coded digital tokens ofthe first class and second client device information; responsive toreceiving the instruction, cryptographically sign using a mint key eachof the new set of coded digital tokens, each of the new set of codedtokens including information sufficient to confirm the second clientdevice is the original recipient that token, and send the new set ofsigned coded digital tokens to the second client device.